Current Project: RPG Toolkit, codename "M3"

[Ace Pace]

Thats a horrible name then, Actor, character, object, anything is better then Event.

But an event need not be an object. It might be a dungeon initalisation script, it might be an invisible warp tile or a set location battle.

Then whats it doing in the graphics module when it needs to be in the game/map status. You gotta ask yourself in the graphics system, 'does that thing belong here, or in the main module'. This is fairly open and shut unlike our discussions on where Tile information needs to go to.

Haven't decided for sure, but I am leaning towards no. It would add too much complexity to the animation system and make it much harder to use.

Lighting is needed in 3d, but in 2d I think I can get away without it. The closest I will get is the day / night system.

A day and night system can easily be expanded as full screen shaders, good enough for me.

quote]
Yeah, that will probably work. Perhaps do 3d math internally, with a base line (the bottom of the sprite) as the ground, then draw the result on the 2d plane.

Will see how complex it is when I get to coding it (probably weeks away still). If it is too hard for either me to code or the end user to understand, I'll leave it out. After all, frames can always be auto generated before hand in things like GIMP or Photoshop, etc.

True, though doing the math itself is beyond me so I'll leave it to you to figure it out.

[Destructionator XV]

Then whats it doing in the graphics module when it needs to be in the game/map status. You gotta ask yourself in the graphics system, 'does that thing belong here, or in the main module'. This is fairly open and shut unlike our discussions on where Tile information needs to go to.

Some events need to be drawn. An event class is a nontrivial construct that covers a variety of topics: drawing, scripting, flags.

When it is graphics time, the main redraw function calls many object's redraw functions, which in turn call their animation member's redraw function, which calls it's current image redraw function, which will either copy a pixmap onto the buffer, or call a user defined script, which might can other sub animations. Animations and story related pixmaps are the only user defined objects that actually draw to the screen, but almost every object is built ontop of this.

It does this recursivly until all objects that might potentially have graphics have had their chance to draw to the buffer. Then finally, the buffer is drawn to the screen.

So yes, the graphics control will iterate through all events and give them a chance to draw, but that is not all they do. Events have a graphical component, and a game script component. They also have many of the same flags that a tile has about if you can step on it or not.

Graphics control also calls player characters to draw, but the player character is a big collection of stats too. Just because graphics control calls it doesn't mean it is a graphics only object.

A day and night system can easily be expanded as full screen shaders, good enough for me.

I forsee a number of limitations with that system. Night time is not a purely graphical thing: it also has the potential to change random battles, NPC locations, inn costs, font color (see Dragon Warrior 3 for the NES to see what I mean)

Also, a shader on top does not adequatly address things like artifical lighting; that would require changes to the tile system, embedding more and more graphic information into them. Some tiles might want to change entirely when night hits, like a peaceful town becoming a Satanic Pit of Evil Hell when night falls.

It can't add something like a moon and stars to a sky image.

It might be useful in some situations, but providing an alternative frame will be easier in almost any situation.

[Ace Pace]

I was more wondering if you implement night frame not as a frame(or maybe as an overlay to a frame) but as basicly a shade to affect the characters/boxs to be darker. That can open a door to neat stuff.

[Destructionator XV]

That sounds like a pretty good idea. I'll have to play with that a little.

[Ace Pace]

Day night is basicly several things: A new frame of the place if needed, some overlays such as lights or stuff(for a town) and a giant effect to make everything darker. The latter, the implementation of it should be as configurable as possible.

[Mayabird]

What kind of music files? I've made a few midis that are basically game music (it's kind of a long story why) and I could easily make more.

Either that or the road could be accessable anywhere, but without encounters. It'd be a fast way to travel before getting something flying.

Like in Final Fantasy 8. Pity they didn't use that idea throughout the whole game instead of just on Balamb.

Yeah, that is definitaly a good idea, and I will certainly implement that.

Cool. Thanks!

Additional question: can you also modify movement speeds? Would "downstream" in a boat be faster than "upstream"? Would a car travel faster than someone on foot? Can the characters run around in the cities instead of walking tile by tile?

Low flying airships: hot air balloons. Limited range and height, kinda slow, but it's flying. [/quote]

[Destructionator XV]

What kind of music files? I've made a few midis that are basically game music (it's kind of a long story why) and I could easily make more.

Anything will do. Not sure if I will be able to support MIDI in the final project, but even if not, I can always convert them to whatever format I do use. (Also, midi is the only format that is feasable for us to do ourselves; surely we don't have an orchestra available to do a digital recording)

But yeah, midi is awesome. And also, did you create these yourself (i.e., do you hold the copyright on them)? I will probably want to modify and distribute as well, and don't want a licensing nightmare.

Additional question: can you also modify movement speeds?

Yes, for different vehicles. What kind of airship doesn't zip across the map? (Except for the FF8 airships, but they make up for it with the coolness factor)

Speed will be something like ticks per tile (a tick is 1/20 of a second, and is the base unit of timing for animation in the program) and adjustable in the vehicle editor (not yet even begun but it will be in a few weeks)

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.

Can the characters run around in the cities instead of walking tile by tile?

Like Final Fantasy 6 with sprint shoes? I haven't decided yet. I think I will though, since otherwise great games become boring thanks to slow walking speeds (see Phantasy Star 2).

And it would still be tile by tile, because each individual step on a tile is important to things like collision detection and random battles, but it would increase the tile per second speed.

Low flying airships: hot air balloons. Limited range and height, kinda slow, but it's flying.

Certainly a possibility, and with the vehicle editor, you can pretty easily do whatever you wanted!

[Mayabird]

What kind of music files? I've made a few midis that are basically game music (it's kind of a long story why) and I could easily make more.

Anything will do. Not sure if I will be able to support MIDI in the final project, but even if not, I can always convert them to whatever format I do use. (Also, midi is the only format that is feasable for us to do ourselves; surely we don't have an orchestra available to do a digital recording)

But yeah, midi is awesome. And also, did you create these yourself (i.e., do you hold the copyright on them)? I will probably want to modify and distribute as well, and don't want a licensing nightmare.

Yeah, I made them myself. My own music and everything. Don't worry, I won't sue.

A quick example: Possible "going to sleep" music

Though if we really, really, really wanted a digital recording, we do have an orchestra here.

Low flying airships: hot air balloons. Limited range and height, kinda slow, but it's flying.

Certainly a possibility, and with the vehicle editor, you can pretty easily do whatever you wanted!

COOL!

[Destructionator XV]

Now, I am going to take a moment and explain my current ideas for the character system. Note that I have thus far written no code for characters, so everything here may be subject to change down the line. That also means it is still open to discussion too!

First of all, I am describing player characters here. Monsters, and to a lesser extent, NPCs will share many, but not all of these characteristics. A monster will probably be a superset of character, since they also need to have some kind of AI since they are computer controlled in battle.

Every character has at least 3 animations associated with him: a sprite for facing left, up, and down. Right may be set as a separate animation, or just be the left animation flipped horizontally. I would suggest a separate animation, and might force that. If diagonal movement is enabled, the character will need 2 more for facing the diagonal directions.

These sprites may be either 16x16 pixels or 16x32 pixels. If 16x32 is selected, the character's upper body (the top half of their sprite) will always be displayed on top of terrain, including walls. This makes them look more realistic (see Phantasy Star 4 for a good example), though tall sprites might look worse in battle, I'm not sure yet.

A character may also have several other animations associated with it: portraits to display in messageboxes when the character is talking. There may be more than one to have portraits of different emotions, like in Lunar. The portrait displayed is determined by the script programmer when he creates the messagebox. Their default portrait is also displayed in their status screen.

Player characters may have text that is displayed when the player presses search on an empty tile, like in Phantasy Star 4. ("Stop wasting time, there's nothing here!" or "There is noone to whom to talk in that direction") This is optional, and my be disabled in the game config file.

Characters have a name, which I will probably limit to 16 characters in length. This name is set in the Character Editor, and if the game config permits it, may be changed by the player when the character joins your party.

You may have up to 5 characters in your party at any given time, though the total number of player characters in the game is unlimited. Changing characters in and out of your party is done by the script system, or, if the game config allows it, may be done at save points by the player.

Characters, related to the above, can have 3 states: in your party, available, or unavailable. Available means they can be swapped out by the player at save points.

Each character has his own individual inventory (unless the game config overrides this and makes it central to the party, which I may or may not support). I will probably limit this to 32 objects, or perhaps make it configurable in the character editor. Items he has equipped may or may not be in the inventory (I haven't decided yet). (Side note: in M2, the equipped stuff was separate from the item inventory, but the character could only carry the equipped item and one other for each slot. He could carry an equipped helmet, and one unequipped helmet. The equipped armour, and the unequipped armour, etc. I might bring this system back, as I rather liked it.)

A character has 5 slots in which he can equip stuff: left hand, right hand, head, body, and accessory, similar to Final Fantasy Tactics. As I said above, the M2 system might be brought back, otherwise equipped items will be pulled from the inventory in some way.

Weapons and shields go in the hands, and some weapons will take both hands, meaning that the character can not carry a shield with it. If a weapon (or shield) takes one hand, the character may equip two at once. The item equipped in the off hand will have a small performance penalty. Job abilities (see below) may be able to override this. Note that the character's dominant hand can be selected in the character editor.

Equipable items may have spells associated with them, so you can use them "as an item" to cast those spells. They can have a limited number of uses before breaking, just like items (see spell and item section for details (will be a later post)). They also have many modifier stats for the character (see Equipable Items section for details (will be a later post))

Characters can learn two types of magic: traditional MP using spells, and limited number of burst spells per spell level (a hybrid of Phantasy Star 4's special skills and Final Fantasy 1's magic system.)

The MP using spells will be referred to as ``magic" and the burst spells will be referred to as ``skills" from now on.

Skills may be granted to a character either from leveling up, or a story event (includes treasure boxes and shops).

Magic is learned either by character leveling up, job leveling up, or spending "points" to earn it (like is done in Final Fantasy Tactics). These points are granted on level ups.

I would like to again take a moment to revisit M2: in M2, a character had a limited number of spells he could learn, and had to learn spells in a tree format (must know Fire1 before learning Fire2, Ice1 before learning Ice2 etc). If his spell list was full, you would have to unlearn an old spell to learn a new spell (kinda like Pokemon in that sense). I liked that system, and might keep it.

Combo spells will certainly exist, but I am not sure in what way yet. Perhaps like Phantasy Star 4 (what a great game!) or perhaps like Chrono Trigger. Or maybe something new. I experimented with a system in M2 that would try to combine spells on a math level, but it wasn't as cool as I'd hoped. Though, perhaps, I can revisit that idea and do it right this time.

I will revisit the specifics of the magic system in a later post, please leave your opinions here, an innovative magic system can make a good game great or a great game outstanding (remember materia! What a blast.)

Characters level up by gaining experience points. The number of points they need for next level is set by a formula in the character editor: it can be exponential, linear, or quadratic. In the editor, you can adjust the coefficents, and view graphs and tables of your results. Maybe even a multi part equation (e.g. linear until level 10, then quadratic until 50, then exponential up to 99) will be allowed.

Balancing experience points gained to points needed is one of the hardest parts of making a cRPG. I will try to do some math so I can suggest sensible numbers, but much will still be in the hand of the content creator.

On level up, the character obviously gets stat gains. The size of these gains will be determined by the character's base stats, and his job (in way unknown so far, will investigate further when I explain the job system). There is also a random component based on how high your stats are.

Every few levels, you are granted a random number of points, which you can distribute manually to your character. These points can be spent on bonus stats, new spells, or saved up (if saved up, they accumulate faster). I did this in M2, and it worked pretty well in allowing more customization, so I am keeping it.

Next post, I explain the stats and some potential forumlas used in battles. After that, jobs.

Any comments are welcome on these concepts, they are going to make the game engine unique or boring and are all open to discussion.

[Mayabird]

This is so cool.

I've been thinking about a system where there are multiple ways of doing something. A very simple example would be getting a new weapon, like a sword. You want a new sword. Do you make it yourself or buy it from someone? Time or money?

Learning skills/spells could be done in a similar manner. You could go to a mage's tower (or something) and pay out the nose (money, skill points, whatever) to quickly learn a new spell, or buy the scroll yourself and laborously learn it by using it over and over. Sure, it'd be easier in a lot of ways to just go to the tower, but Podunk Starting Town won't have one, and to get anything really good, you'll have to travel a long way. Skills could be learned from trainers in a similar fashion.

Proficiency with weapons could also go along those lines. Tired of your healer sitting back and not doing much during battles? Teach her to use a slingshot. Go to a weapon's trainer. Of course, different stats and different classes mean longer learning times or penalties.



Would it be possible to create randomly-generated areas? I was thinking like a swamp or an erupting volcano, somewhere that the terrain would be constantly changing. There would always be a way through, but it'd be different every time. I'd have another choice here: hire a local guide to take you through, or struggle it out yourself.

[Ra]

I'm loving this more and more as I hear the details.

These sprites may be either 16x16 pixels or 16x32 pixels. If 16x32 is selected, the character's upper body (the top half of their sprite) will always be displayed on top of terrain, including walls. This makes them look more realistic (see Phantasy Star 4 for a good example), though tall sprites might look worse in battle, I'm not sure yet.

Glad you brought this up. Being the n00b that I am, I was making sprites that were actually between 16 and 32 px in height, but oddly enough 16 px in width. I guess I was just lucky there. I'll revisit my images, and try and reduce them to 16 x 16, though that might take some doing.

Though for your convenience, I was already restricting the colors to four in each sprite.

A character may also have several other animations associated with it: portraits to display in messageboxes when the character is talking. There may be more than one to have portraits of different emotions, like in Lunar. The portrait displayed is determined by the script programmer when he creates the messagebox. Their default portrait is also displayed in their status screen.

I definitely love this idea, too. I'll also look into making some protraits - again in four colors - to go with each character sprite I'm creating. What will the portrait dimensions be? About 38 x 60 or somewhere in that neightborhood?

[Destructionator XV]

I've been thinking about a system where there are multiple ways of doing something.

That sounds pretty awesome. Should be able to maintain enough flexability in the system to allow this.

Would it be possible to create randomly-generated areas?

Yes, using the scripting system. The script system will allow you to change almost anything in game that you want (it extends most the programmable capability to the user).

You would need a map file to get it started, but then you have its script do the rest. It would be a nontrivial script, but when I get to writing that code, perhaps I can write in some more functionality to make this easier.

The script would then be able to see if you hired a guide, and make the guide programmatically know where to go. Again, a nontrivial script, but certainly possible, and I'll see what I can do to make this easier in the engine itself.

Glad you brought this up. Being the n00b that I am, I was making sprites that were actually between 16 and 32 px in height, but oddly enough 16 px in width. I guess I was just lucky there. I'll revisit my images, and try and reduce them to 16 x 16, though that might take some doing.

Remember if it is big and you need the detail, you can make it a compound tile (which can be any multiple of 16) or a tall character (16x32).

Though for your convenience, I was already restricting the colors to four in each sprite.

That is actually not needed, the animation system supports full 32 bit color in all images. The game might be somewhat low tech in itself, but it still runs or rather powerful computers, so go nuts with your colors, and remember you can use full transparancy too. (Though if you don't do this yourself, I'll go back and add it with my automated tools)

Aside from the size limits, you can pretty well go nuts on this.

[Destructionator XV]

Yeah, I made them myself. My own music and everything. Don't worry, I won't sue.

That's awesome. I have such a hard time writing music myself. As my code may look magical to you, music looks magical to me.

May I ask what programs you are using in creation of the midis?

Possible "going to sleep" music

I like it! Anything else you have will certainly be appriciated!



...there was something else I was going to add to this post, but I bloody forgot what it was. It will come back to me...

[SirNitram]

If I could program, or make graphics, or really do anything but write, I'd suddenly be infused with energy to make a Netheril-era RPG with alot of open-ended stuff, then see if the rights could be gotten to sell it.

But that's wishful thinking.

[Destructionator XV]

Well, I can't remember what I was going to add to that last post (note to self: I think it was M2 event system and why it is called M in the first place, some history on the series...), so I will continue with my talk about the character system with stats. I will also touch upon the battle system a little.

First of all, let me explain how M2's stat system worked. It worked pretty well, and I will probably recreate it as the base of M3's stat system.

I had 6 main base stats (inspired by FF8), speed, dex, hit and evade percents, and some derived stats. Let's get started with the base stats.

1. Str (strength): this stat formed the base which is used in deriving the character's attack power. base str + job str + weapon = attack power.
2. Vit (vitality): Formed the base for defense power. Base vit + job vit + helmet + armor = defense power.
3. Mag (magic): Base of magic attack. Base mag + job mag = magic attack.
4. Spr (spirit): Base of magic defense. Base spr + job spr = magic defense
5. Sta (stamina): Base of hit points: Sta * 5 = Max HP
6. Int (intelligence): Base of magic points: Int * 3 = Max MP

The base stats were increased by the current job stat divided by two each level up, and your bonus points (explained in the character section) could be applied to these, on a one for one ratio.

Next, the level 2 base stats:

1. Spd (speed): This determined how fast the character got his turn in battle. It would max out at 15, and would have the job speed added to it directly. It would only increase one point every 10 levels, or you could spend 5 bonus points to get one point increase.
2. Dex (dexterity): This controled how much stuff you could have equipped. Each equipable item in M2 had a dex value, and it would subtract that from your dex when you equipped it. If your dex dropped below zero, you could not equip anything more.
   
   Dex = base dex + job dex + character's current level - (all equipped stuff);

Now, the percentages:

Hit%: inspired by the stat of the same name in Final Fantasy 1, this determined two things: what your odds of hitting the enemy were, and how many hits you would get on him.

Each time you hit the enemy, your hit percent would be cut in half, and you would try to take a second hit. If you miss, your attack was over, if you hit, it would be cut in half again and you take another swing. It continues until you missed. Usally 2 hits were common, and 4 or 5 were rare, but awesome when they connected.

Hit% = weapon hit stat + base stat + job stat. It did not increase with new levels. A common value would be about 90%.

Evade%: Each time the enemy passes his hit% check and tries to hit you, you could take an evade chance. If you evade, the attack misses (though the enemy could take another swing; that was based on his hit%)

Evade starts off high, about 70%, dependant on character and job. It did not increase with level ups, and was decreased for each piece of armour equipped (again, inspired by FF1). When armoured up, a common value was about 25%.

Now, the derived stats: HP, MP, Atk, and Def:

HP, MP: this much is obvious. M2 allowed your HP to drop below zero though; the farther below zero it was, the lesser chance that life magic would work on you (overkill means getting back up is not easy at all).

Then attack and defense were used to determine damage with a formula like this:

damage = (((attack * 2) - defense) * random between 95% and 105%) + random between 0 and 3.

If damage after that was less than or equal to zero, damage would randomly equal zero or one.

This formula kept things interesting; it was predectable, but not boring. Attack was multiplied by two to counter act the effects of having both a helmet and armour on the defended, and the relativly high evade percents.

And now magic damage:

magic damage = spell damage value + magic attack - magic defense * random between 70% and 100%.

(and of course, elemental adjustments after this, which were simple percentages)

Magic defense would be randomly weakened because I like powerful magic. Black mages should be something to fear, not a waste of time (yes, I am looking at you FF8 and 9).

Also keep in mind that healing magic was negative magic damage in that game, so high magic defense had its disadvantages too.


What I explained here was my old system in M2, but as I said, I liked it, and will probably use it again, with a little more refinement. Any more suggestions on this topic?

[LadyTevar]

Would it be possible to create randomly-generated areas?

Yes, using the scripting system. The script system will allow you to change almost anything in game that you want (it extends most the programmable capability to the user).

You would need a map file to get it started, but then you have its script do the rest. It would be a nontrivial script, but when I get to writing that code, perhaps I can write in some more functionality to make this easier.

The script would then be able to see if you hired a guide, and make the guide programmatically know where to go. Again, a nontrivial script, but certainly possible, and I'll see what I can do to make this easier in the engine itself.

I am reminded of the Volcano in FF3/6, where the safe passage would change.

[Something Awesome]

This seems very much influenced by the RPG Maker PS game. One of the major flaws in that was in making scripted scenes; you couldn't make it execute multiple events at once, as in having two objects move simultaneously yet independently. I'm thinking like the beginning of Lunar 2 with Hiro running around the dungeon being chased by all sorts of baddies and boulders and such. Can M3 handle that?

And how about the creation interface? Do I have to type stuff, or can I be lazy and select functions from a drop-down menu?

And you need Mech support. Like Xenogears.

And in FF7, did attaching Materia to equipment affect the equipment? What if you could "imbue" items with magic, but they didn't just add elemental, but also functioned like adding upgrade items in KotOR 2. Combinations of magic could do different things, too. Sword + Lightning = Paralyze effect, Sword + Haste = Auto-haste, Sword + Lightning + Haste = Extra Attack? Some items would react differently to different spells, like adding Fire to an Icebrand just results in a rusty hilt and a puddle.

[LadyTevar]

This seems very much influenced by the RPG Maker PS game. One of the major flaws in that was in making scripted scenes; you couldn't make it execute multiple events at once, as in having two objects move simultaneously yet independently. I'm thinking like the beginning of Lunar 2 with Hiro running around the dungeon being chased by all sorts of baddies and boulders and such. Can M3 handle that?

And how about the creation interface? Do I have to type stuff, or can I be lazy and select functions from a drop-down menu?

And you need Mech support. Like Xenogears.

Or Magitech Armor from FF6?

And in FF7, did attaching Materia to equipment affect the equipment? What if you could "imbue" items with magic, but they didn't just add elemental, but also functioned like adding upgrade items in KotOR 2. Combinations of magic could do different things, too. Sword + Lightning = Paralyze effect, Sword + Haste = Auto-haste, Sword + Lightning + Haste = Extra Attack? Some items would react differently to different spells, like adding Fire to an Icebrand just results in a rusty hilt and a puddle.

No, it didn't upgrade like that.

To add an elemental effect you had to pair an 'add elemental' and a elemental materia together, just like you needed to pair Cure with All to have your Cure spells hit all party members

[Destructionator XV]

This seems very much influenced by the RPG Maker PS game.

Some of it is, though I found that game way too limiting (which did spur the devlopment of M2 as you know).

I want to put together all the best ideas I have ever seen into one powerful, user extensible engine. It is going to take some time (remember my estimation to core functionality is 4-6 weeks right now, and that will probably still not be enough to be done_ but oh man it will be so worth it.

One of the major flaws in that was in making scripted scenes; you couldn't make it execute multiple events at once, as in having two objects move simultaneously yet independently.

Two objects will be easy to do: any script, except in the animation subsystem, has access to the entire programmable interface, and all active objects. This will make more sense when I finally write up the script documentation.

Now, as for two different scripts running at once, I am going to say probably not. That would mean you as the scripter would have to worry about multi threading: and that will be a nightmare. No one writing these scripters will understand threading and race conditions and mutexes and semaphores and syncronaztion. Writing the engine to support threaded scripts will be hell for me too, and I would probably never finish.

So only one user script can be run at once, but all scripts can access the whole system, so you can do things like you want.

I'm thinking like the beginning of Lunar 2 with Hiro running around the dungeon being chased by all sorts of baddies and boulders and such. Can M3 handle that?

One master script in an event controls the other events. Not the easiest task, but with the documentation and a sane design, it shouldn't be so bad.

And how about the creation interface? Do I have to type stuff, or can I be lazy and select functions from a drop-down menu?

Both. It has auto complete. Play with the animation editor, it has a bit of that already.

The main script edit control, which will be a while down the line, will have common tasks easily accessible in menus and I am hoping to have some kind of point and click for many functions too.

And you need Mech support. Like Xenogears.

wtf is it?

And in FF7, did attaching Materia to equipment affect the equipment?

No, it affects the character, not the equipment. Except for the elementals.

What if you could "imbue" items with magic, but they didn't just add elemental, but also functioned like adding upgrade items in KotOR 2. Combinations of magic could do different things, too. Sword + Lightning = Paralyze effect, Sword + Haste = Auto-haste, Sword + Lightning + Haste = Extra Attack? Some items would react differently to different spells, like adding Fire to an Icebrand just results in a rusty hilt and a puddle.

Maybe. This would add many things to the spell and item system, but I think it is doable, especially considering the weapon and item systems are rather simple anyways.

I'll see how it goes as I get around to that part of the code.

[Destructionator XV]

Or Magitech Armor from FF6?

Magitek armor would be pretty easy to do as separate characters which inherit stats from their normal character, or hell, since Magitek's stats would be so different than the character itself, it could be an entirely different character that happens to share some artwork.

[Destructionator XV]

As promised, here are my ideas for the job system, but my fingers are getting really tired by typing this all day, so after this post I think I am heading to bed. Then tomorrow, hopefully, I'll get back to writing code. Anyhow, let's get started.

Jobs are something I am thinking about hard coding most the base charactistics. Something like the blue mage would be a bitch to do in the script only (though possible), so I will be coding powers like that into the engine itself, then the job editor (oh god I am going to be writing alot of editors...) will let you string together these base charactistics, list their stats and spells, then you go to the character and add artwork for it (or have generic art for the jobs; the difference between Final Fantasy 5 and Final Fantasy Tactics) You can also set the prerequisits for thejob in the editor.

My eyes hurt. I'm gonna rush through this description now and clean it up after I get some sleep.

OK, types of job systems:

1. The player has no option to control the jobs. A character is set as one job, and can never be changed. Like Final Fantasy 6.
2. The player can pick the character's job when he joins the party, but it can never be changed. Like Final Fantasy 1.
3. The player can change the character's job at any time. Like Final Fantasy Tactics.
4. The player picks a job when the character joins the team, and can change it later, but only under special circumstances, like going to a shrine. Like Dragon Warrior 3.
5. The player can choose jobs regularly, but not at any time. Perhaps only once a level, or perhaps once you gather enough points on your current job. Similar to Final Fantasy 5.

Supporting all these systems should be easy to do, so I will. The content creator picks his preferred system for the game in the game config file.


blah, I need sleep.

[Mayabird]

Yeah, I made them myself. My own music and everything. Don't worry, I won't sue.

That's awesome. I have such a hard time writing music myself. As my code may look magical to you, music looks magical to me.

May I ask what programs you are using in creation of the midis?

Possible "going to sleep" music

I like it! Anything else you have will certainly be appriciated!
.

Umm, I had a free program I downloaded on my computer for a while. I don't remember what it was called, but a little Google magic should dig it back up or an equivalent.

And thank you!


Do you need any help or advice on job classes?

[Something Awesome]

And you need Mech support. Like Xenogears.

wtf is it?

Not quite Magitek style. With the push of a button, your characters would enter their Gears if there was room (like on the world map or certain other areas, but inside, say, a house). The Gears were infinitely more powerful than the standard character, but so were the monsters you fought in them. While the battle system was similar between character and Gear combat, there were many differences.

Essentially, it was just swapping out your character for a bigger character. Imagine a Gundam RPG where you are sometimes taking a stroll through a Musai, combatting filthy invading Feds, then you hop into your Zaku to blow up White Base. Or the final Char v. Amuro duel at A Baoa Qu: sometimes in Suits, sometimes not. But there would be subtle differences combat, and you could only swap out characters for themselves (say, your team consists of Char, Ramba Ral, and Garma on foot, then you need to do a MS battle, you couldn't just swap out for Char's Zaku, Char's Gelgoog, and the Zeong.)

And you haven't played Xenogears?

[Destructionator XV]

Any ideas you have for them would be awesome. Try to explain your ideas in terms of base characteristics, not just something like specific stats (though those facts will obviously be important later on)

When coding the engine, it is the base things I will need to worry about. Like magic system (mages, enemy skills) or special powers (I am reminded of things like the geomancer). Monks and knights are easy to do; they are primarily stat based. Original or even just cool ideas from elsewhere for special classes is where the awesome is, and all help (on any topic) is great.

[SirNitram]

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.

I mean things like this. A Mage and an Engineer(Throwing it out here, just stay with me) mixed character could perhaps go on to a class that makes a large Golem that can 'stand in' when summoned(Much like the mecha system mentioned). 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.