Current Project: RPG Toolkit, codename "M3"

[Destructionator XV]

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.

You could, but giving the player control when travelling in space seems pretty weak. Space is mostly empty, there would be nothing to see for long distances of nothingness.

The automatic cut scene idea of space travel is so much cooler and more practical.

[Ace Pace]

Yes, I'm just saying that if needed, thats an option.

Another note: Using the system you provided, devs can do pretty much any kind of terrain. One interesting thing would be a waterworld. The towns have an overdraw capability letting you walk under them.

[Destructionator XV]

Time for an overview of what I have in mind for the map system.

As you know by now, a map is at its core a collection of tiles that is the most important part of a dungeon, but it is much more than just tiles.

A map has a sizeable graphical component, which I have touched upon already. It has three main layers:

1. The wallpaper. This is a full screen animation that is drawn under everything else. It is optional, but makes most maps much cooler.
   
   Wallpapers can actually be bigger or smaller than the size of the screen (640x480 pixels). If smaller, it is tiled in the background, and if larger, it scrolls with the character as you move, at 1/2 the speed of the characters. This allows you to have 3dish effects under your terrain. The wallpaper is always looped if needed.
2. The terrain. This is the tiles themselves, and any place outside the map's confines can be either black, looping, or transparent. Black is good for caves, as the edge of the cave would be nothing. Transparent is good for towers, etc, where you would want to see the wallpaper by default, and looping is for world maps, where if you keep going in one direction, you end up back where you started.
3. The overlay. This is similar to the wallpaper in most ways, but it is drawn on top of everything else. It moves with your characters at 2x the speed, unless it is set to be static in a control flag.

In addition to the graphical component, maps have another layer: the enemy domain layer. This layer decides what kind of random battles you can get on that square.

The enemy domain layer is a layer for all tiles that contains a number of an enemy domain (see below).

An enemy domain is a list of enemies and the probability that you will encounter them in any given battle. There can be multiple enemy domain sets for different vehicles, such as on grass when walking, you might fight slimes and imps, but on the same grass if in an airship, you might have to fight sky dragons. It would look something like this:

Domain 1:
walking: Slime (90%), Imp (5%) , Slime and Imp (5%)
flying: Sky Dragon (70%), Sky Dragon x2 (30%)
sailing: Shark (10%), Sahag (90%); Shark (25%)
(the last one means one enemy will usally be just a sahag, but 1/4 battles will add a second shark to the mix)

The GUI editor I write will try to make this simpler, so it makes sense.

A dungeon also has an optional background music, which is started whenever the character enters the dungeon. If no BGM is set, the song what was playing before entering the dungeon continues playing uninterrupted. The BGM is always looped forever until told to stop.

A dungeon has an initialisation and exit script, that are always run then the player enters and leaves the dungeon.

Dungeons have events which can be pre initialised or dynamically altered in one of the scripts. If preinitialized, you can set them on any x,y position. Remember events are anything from townspeople to treasure boxes to stairs.

A dungeon also has a set of flags:

• Save: determines if you can save at any place in the dungeon. If this is not set, you must save at a save point in the dungeon.
• Black default background: if set, the default background is black instead of transparent.
• Loops: if set, the map loops forever, like a world map
• Can use vehicles (array): if set, you can use that vehicle on the map. There is one flag for each vehicle in the active set.
• Random battles: if set, you can encounter random battles on the map. If not set, there will be no fights here.
• Night advances: if this is set, the in game day / night counter advances with each step. If not, time stands still. Should be set on the world map, but not in towns, etc.

There is surely more that I will think about when the time comes to actually code it. Any suggestions are, as always, welcome.

[Mayabird]

On the lesser-used classes:

Alright, let's be honest here. Though games might have classes like "bard" or "engineer" or "talker to plants" we don't really use those much. They mostly suck in battle, don't have stuff that makes them worthwhile compared to the classes the game designers actually cared about, and who needs strategy when you're twenty-five levels above your enemies?

To make some of the lesser-used classes worthwhile, I propose a system of out-of-battle experience. Characters can receive experience in battles, but they can also do things outside of battles to obtain experience. For example, your pyrotechnics engineering character can make grenades outside of battle, which can be used in battle to blow stuff up or be sold or something. For each grenade, the engineer gets some experience. The bard sings "Java Jitterbug" to make you run twice as fast, and gets experience for that. A targeteer might man the turrets of your airship, and gets experience for shooting down dragons (it's not like the guy with the sword is going to stand on the top and swing the sword at the dragon in the distance). And so on.


On space maps: I think it would be more like a super world map, except only showing locations (Planet One, Planet Two, Moon One, Moon Two, Big Asteroid, Lucy with Diamonds) which when selected warp you to that location. Then the planets themselves could have their own world maps.

Since I'm done with work for the day, I'm going to start on writing some more music.

[Ace Pace]

Experiance should be easy to do, just in an event file mention it gives exp.

[Destructionator XV]

Alright, let's be honest here. Though games might have classes like "bard" or "engineer" or "talker to plants" we don't really use those much. They mostly suck in battle, don't have stuff that makes them worthwhile compared to the classes the game designers actually cared about, and who needs strategy when you're twenty-five levels above your enemies?

Hahaha, who remembers the bard Edward? What a useless bloke.

In most the games, the good jobs always came back to the FF1 main 6: fighter, thief (though they often sucked too until ninja, who are awesome), red mage, black mage, white mage, and black belt (which I am mixed on).

And then the blue mage and samurai were kinda cool. The others: waste of time. If I use them at all, it was just to open up later jobs.

To make some of the lesser-used classes worthwhile, I propose a system of out-of-battle experience. Characters can receive experience in battles, but they can also do things outside of battles to obtain experience. For example, your pyrotechnics engineering character can make grenades outside of battle, which can be used in battle to blow stuff up or be sold or something. For each grenade, the engineer gets some experience.

As Ace said, this is possible in the script system, add a line after it saying caster.exp+=50 or whatever.

This sounds like a pretty good plan.

(it's not like the guy with the sword is going to stand on the top and swing the sword at the dragon in the distance).

Good thing you mentioned that, that is something I forgot about. Need to incorporate a long range weapon system, similar to FF7 maybe.

On space maps: <snip>

Sounds like the Final Fantasy Tactics world map, you click the location, you move there and enter. That should work.

[LadyTevar]

Don't forget the Summoner job. Most of the recent FFs have had it tied to WhiteMagic, but Rydia from FF4/2 was a Black Mage/summoner. She lost access to White Magic when she learned more Summon magic

[Destructionator XV]

Don't forget the Summoner job. Most of the recent FFs have had it tied to WhiteMagic, but Rydia from FF4/2 was a Black Mage/summoner. She lost access to White Magic when she learned more Summon magic

Yup. I want to have two kinds of summoners: one just summons the powerful spells, like FF4 -9. The other kind summons a monster to take his place for the battle, kinda like FF 10.

[Mayabird]

Alright, two more little pieces of music.

Short fanfare

Spooky

The fanfare will eventually be the beginning of a really pretentious march, which I'm still working on. It could just be played once without being on loop, though:

*Fanfare* "All hail the Marchioness!" *parade goes through, and there are cheering sounds before the music starts back up*


A long-range weapon system could be related to the character setup. An archer, slinger, gunman, whatever could be in back, where the meat shields can protect them and still do a lot of damage. It kinda defeats the purpose of ranged weapons if you take the range out of it. They shouldn't have people running up to them and hitting them with a club. They should shoot the people running at them from fifty meters away. Ranged types probably wouldn't be wearing much in the way of defensive armor, but they should probably load up on magic protection, since that's ranged too.

Yeah, the FF Tactics map! That would work great for a space map.

[Destructionator XV]

One song submission of my own:

There was one song my brother and I wrote for M2 some time ago. I wanted to write a overworld song, but failed. My brother took its corpse and added some randomly generated something to it, and it sounded ok, so it was renamed end boss.

Take a listen

[Mayabird]

That's a pretty cool song. Would you mind if I took it and remixed it a bit, cleaned it up and such so it sounded more SNES than NES?

There was something else I wanted to say, but I can't remember it now. Oh well, I'll ask later.

[Destructionator XV]

I am talking to myself here while working on a problem; feel free to skip the rest of this post.

You are not expected to understand this.

While writing the vehicle class, I started to think how it shares characteristics with player characters and NPCs: the fact that it has animations to be displayed on the world map.

Obviously, the right thing to do then would be to make an abstract base class, which I am calling actor, which provides this functionality, and would be inherited by the three above mentioned classes.

So far, so good, but then I also realised that vehicle can have stats, just like a player character and a monster, but not like a NPC.

Again, it seems pretty obvious: make a base class called stats, and have the necessary classes inherit it.

But now we enter a realm which I have never truly treaded before: multiple inheritance. And to make things worse, the base classes might need to inherit QObject so they can have signals, slots, and be accessed by the script system.

Now I am into virtual multiple inheritance, which I have never actually coded or even read about before.

Well, apparently it gets worse, as Qt's moc doesn't have a full understanding of multiple inheritance either, so I have to follow some more rules to make it work.

So I start thinking about making stats and actor abstract classes that are NOT QObjects, which means I could now not worry about the virtual multiple inheritance issue, and at the same time, not worry about moc's technicalities.

But that means giving up signals and slots too, and the wrapper classes for the QSA interface will have multiple duplicated call through functions, which seems like wasted work, but there may be no way around it.

stats will be fine without signals and slots, and actor currently uses it as a pass through to the underlying active animation. If I eliminate that, I will need to pass pointers for callback functions, which is a hassle for multiple reasons, not the least of which is the base class will need to know about its derived class, which eliminates the whole point of the abstraction!

One possibility would be to eliminate the stats base class, copying its functionality into the derived classes instead, but that also breaks the object oriented design, and will make maintaince harder, especially if I should choose to change damage algorithms, etc.

So, encapsulating the stats is the right thing to do, and abstracting the animations will save code later on, so it seems like the right thing to do.

Side note: should stats be scriptable? Maybe on the character level, but I don't think so. The formulae will be my doing.

It's just how do deal with the QObject inheritance... back to experimentation I guess.

Edit: problem solved. The moc manual says don't do it, so I will use pointers to the animation instead of the signals and slots.

Good to know, as this will certainly come up again as I move on. I am a better programmer today than I was yesterday, so it was all worth it.

[Destructionator XV]

That's a pretty cool song.

Thanks.

Would you mind if I took it and remixed it a bit, cleaned it up and such so it sounded more SNES than NES?

I don't mind; have fun with it!

[Scottish Ninja]

The woes of multiple inheritance... I remember this exchange in Java class while my partner and I were working on our final project.

"So... yeah, we'll use a super-class for the regions, then have each type extend it."

"Wait, but for each of them we have to extend JFrame - so. I'm not sure that we can do that, then."

"Shit."

[Destructionator XV]

I'm not sure Java supports multiple inheritance, at least not in the same sense as C++. Forgive my bad Javaish syntax here; I rarely use it.

What I am doing is something like this:

Code: Select all

class stats{
/* do a bunch of stats related stuff */
};

class actor{
/* take care of graphics stuff on the map */
};

class character extends QObject, stats, actor{
/* add specialised stuff for the character */
};

(QObject is a class provided by the GUI framework I am using)

At this point, character has everything QObject has, everything stats has, and everything actor has, and then its own stuff.


It sounds like what you were trying to do is:

Code: Select all

class region extends JFrame{
/* do the region stuff */
};

class your_thing extends region{

};

Which wouldn't be a real problem at all; that just means your_thing has all the characteristics of region, which in turn inherits JFrame.

Multiple inheritance starts to get ugly when a derived class inherits two or more base classes, which are in turn derived from the same base class, like this:

Code: Select all

class something extends generic_object{

};

class something_else extends generic_object{

};

class whatever extends something, something_else{

};

At this point, class whatever has a problem: it inherits generic_object twice, once through something, and the second time through something_else.

This is where my problem came in, and why I had to research virtual inheritance, which means they inherit pointers to the base class rather than another copy. With the pointers, that ensures there is only one of the base classes existing for the derived class.

However, it turns out my design was slightly flawed anyways, and now I am going about it in a slightly different way. Still using multiple inheritance, but no longer inheriting two derived classes to avoid the virtual mess.

[LadyTevar]

Ok, just so you know, Nitram found a ROM of the old "Secret of Mana" RPG from '94, and I've been playing it. It's been giving me ideas.

Like Multiplayer Functionality... which the original had, but the ROM can't support.

And the idea of 'charging up' an attack to make it stronger. Downside: the more powerful the weapon, the longer it takes to charge. Since the battles are RealTime, like Zelda, taking time to charge up fully opens you up to enemy attacks.

[Destructionator XV]

Time to talk about the elemental system.

When I was asking about social situations a wee bit back, Shark Bait mentioned color theory and the color wheel.

Today, this concept got me thinking about a potential new type of elemental system: an elemental wheel. Here is a color wheel, which I will use as a reference:


Fig. 1

Notice in figure 1 that it is black in the center, then becomes more colourful towards the outside. This shows two important concepts in my idea: elemental vs non elemental (black vs coloured) and different types of elementals (the different hues).

Your character's defense or attack can only hold any one point on this circle, which I will refer to using polar coordinates, since the make sense here and will make the math easier.

A quick refresher on polar coordinates if you have forgotten (skip if you remember how they work):

Any polar coordinate has two values. θ (the Greek letter theta), and r. θ is the angle, and r is the radius. A point is defined as r units away from the origin (the center of the circle) and and angle θ around the circle. θ = 0 is to the right from the center, π/4 is up, π is left, and 3π/4 is down. (Remember π radians is 180°, so 2π = 360°, and the math to convert is simple knowing that). When writing a polar coordinate, r goes first: (r,θ).

Done with math reminder.

A weapon or armour's elemental attribute is defined as a single point on the circle (r,θ), where r is how elemental it is (as opposed to non-elemental) and θ is what kind of elemental.

As I said, a character's elemental attribute is just one point, so it would be defined as the sum of all equipped elementals, using vector addition, with the final sum truncated to remain within the circle.

Valid values for θ are between 0 (inclusive) and 2π (exclusive), and r is between 0 and 1 (inclusive on both).

When attacking, effective element will be attack - defense, again vector subtraction.

Potential damage is the number after the attack and defense numbers have been calculated.

Raw elemental damage = raw damage * attacker's element radius
Raw nonelemental damage = raw damage * (1 - attacker's element radius)

Final damage = elemental damage (calculated below) + raw non elemental damage.

Elemental damage = raw elemental damage * effective element radius * abs(θ from the effective element - θ from the defender's element) / π.

EXCEPT when θ1 = θ2, in which case elemental damage = (effective elemental radius - 1) * raw elemental damage.

The except clause makes absorbing elements possible if you are being hit by your own exact element.

This formula might still need refonement, but I like it thus far.

This formula does account for the situation if an attacker hits someone on the opposite side of the wheel, it will do double damage.

I think this provides a more innovative solution of defending, being weak to, or absorbing elements. Let's define a few examples.

Lightning will be violet on the wheel, fire is red on the wheel, ice is cyan, and water is blue. In all these examples, we are dealing with pure elementals (i.e., no non-elemental component to worry about).

If lightning were to hit fire for a potential damage of 100, how much damage would actually be done?

Lightning's coordinate is (1,5π/8).
Fire's coordinate is (1,π).

Vector subtraction to get the radius is done by:

(the 1s and 2s here should be subscripts)

r = sqrt( ((r1 * cos(θ1)) - (r2*cos(θ2)))^2 + ((r1 * sin(θ1)) - (r2 * sin(θ2)))^2 )

θ = arctan( ((r1 * sin(θ1)) - (r2 * sin(θ2))) / ((r1 * cos(θ1)) - (r2*cos(θ2))))

Where r1 and θ1 is the attacker's coordinate on the circle, and r2 and θ2 is the defender's.

Plugging in the values yields an answer of r = 1.11 and θ = ~ 4.1. Finally plugging into the damage formula will give a damage of 76, unless I made an error.



And I am tired of doing all the math by hand, so I am going to write a program to do it for me before doing any more examples.

[Destructionator XV]

Like Multiplayer Functionality... which the original had, but the ROM can't support.

Since Secret of Mana is real time, multiplayer makes sense: both players can hack and slash together. But what bonus would it give in a classic Final Fantasy style game? Now, FF6 did provide a way for different players to control half the team in battle, but I never used this feature (found it boring).

What exactly would you do multiplayer in a cRPG?

And the idea of 'charging up' an attack to make it stronger. Downside: the more powerful the weapon, the longer it takes to charge. Since the battles are RealTime, like Zelda, taking time to charge up fully opens you up to enemy attacks.

This sounds good. Make charge ups increase your charge time (remember in Final Fantasy Tactics how spells would take forever to go off? I have a system like that in mind too when using ATB: your ATB gague goes up, you input a command, then it goes back down based on the commands speed, and when it hits 0, the command goes off and it starts going up again). So this can be done, even in turn based battles, and sounds like a good idea.

[Destructionator XV]

For the elemental system, I figure I will also support a more traditional system too: a table of elements.

For this system, you simply name elements, and fill out a table explaining how they interact, like this:

Code: Select all

                             D E F E N D I N G
                     Fire               Ice               Lightning
   Fire               100% absorb      200% damage          normal damage
A  Ice                50% damage       100% absorb          70% damage
T  Lightning          80% damage       135% damage          100% absorb
T
A
C
K
I
N
G

You could add as many elements, called whatever you want, to the table and fill out whatever values you want for each cell.


My brother also proposed adding status effects that are tied into elements, like lightning is tied to haste, so if you mix a spell with lightning, it might form haste. Something like that would also be easy to add to the table.

[Mayabird]

And the idea of 'charging up' an attack to make it stronger. Downside: the more powerful the weapon, the longer it takes to charge. Since the battles are RealTime, like Zelda, taking time to charge up fully opens you up to enemy attacks.

This sounds good. Make charge ups increase your charge time (remember in Final Fantasy Tactics how spells would take forever to go off? I have a system like that in mind too when using ATB: your ATB gague goes up, you input a command, then it goes back down based on the commands speed, and when it hits 0, the command goes off and it starts going up again). So this can be done, even in turn based battles, and sounds like a good idea.

It also occured in FFIV. More complex spells/summons like Bahamut or Meteo took freakin' forever to cast.

Before anyone thinks that I've been slacking off, I've been working on longer, more complex songs. Here's a draft example:

Silly fun and goofiness!

I'm about 2/3 of the way through that. It's sometimes a bit hard to write this kind of music, because there can't be an ending. These things have to loop (except that fanfare).


Would this system be able to support non-linear storylines or games with multiple endings?

[Ace Pace]

All in event scripts so I suppose so.

[Destructionator XV]

These things have to loop (except that fanfare).

Aye, and that is going to be hard to do. If they don't loop well, the song gets annoying, no matter how good it was the first time. Luckily, for many songs, the random battle theme can break them up a little so they don't get so monotonous, making the loop problem a little smaller. Of course, they do still need to loop cleanly for those times where there aren't battles.

As a side note: remember the ocean palace in Chrono Trigger? That song didn't really suck, but since the random battles didn't break it up often, it got quickly annoying. Same with the Tyran castle.

But it did make the relief when you get on that elevator all the more sweet...

Would this system be able to support non-linear storylines or games with multiple endings?

Yes it will, again as Ace said, in the script system. Nonlinear story lines are not easy to do (which is why we don't see them more often), but it is possible.

The way I would do it is have a number of little events, which don't overlap too much. That way, you can have related events check switches to see if the previous event was done, and branch off from there. There will be many, many uses of if, switch, and ternary operators in the script.

It will get messy the more interrelated branches you have (so it is more of a web really). Imagine a simple townsperson:

talk( (isEventDone("cave") ? "Good job finishing that cave!" : "You need to go east to the cave.")

And that is just talking. Things get complex fast, but if you have a clear plan ahead of time, it is doable.

Now, multiple endings, Chrono Trigger style, aren't as hard, since the ending terminates the game (by definition). You just keep track of events that are done (which has to be done anyways), and check them when you fight Lavos or whatever, and branch off to another script.

I will teach you how to use the scripts once I start to get them working. You too will be script programmers!

[Ace Pace]

If that example is how the script system will be, I will personally make it my goal to change that. Seriously, that's unreadable.

[Destructionator XV]

If that example is how the script system will be, I will personally make it my goal to change that. Seriously, that's unreadable.

That is one way to use one of the more powerful features of the language.

You could just not use that section of the language. You could rewrite that same thing with an if:

if( isEventDone("cave") )
talk("Good job finishing that cave!");
else
talk("You need to go east to the cave.");

Either way, if you want to have and use a powerful system, there is going to be a learning curve. Better to stick with the established ECMAScript standard and it's well known C like syntax.

Now, if you don't like isEventDone, that is different. I probably won't call it that at all, and the syntax probably won't look like that either. It will probably be more like

Game.Switches("cave").set;

But I haven't decided yet. Now, I am considering doing a preprocessor of the script, allowing you to shorten some names, but I don't know. It will certainly allow the scripter to wrap things in his own classes though, and I will be writing the standard script library at some point.

It is my hope so when it is all done, for simple games, you can just list off actions, probably selected from a GUI menu. But it is not realistic to express advanced logic in a GUI like that, so you are going to have to learn at least conditionals, and that is what it will look like.

[Ace Pace]

If you still have that screenshot of the Freespace 2 scripter, take inspiration.