Author Topic: "Escheron: Twilight over Ragnoth" — progress updates and discussion (Read 122907 times)

Geekboy1011 · « **Reply #15 on:** April 07, 2015, 04:37:57 pm »

The only issue I have with that tile set is it looks kinda bland/forced with the dithering, But I think I will like it regardless! That being said I did like how the previous tilemap felt like it had more depth, But that is subject to tweaking I suppose.

As for the screenie iambian posted he just made it jump to the new coordinates. The system supports making it gracfully pan by the half tile. He just did not code it in. >.> quick screenie much

As for animated tiles. I like them but if we dont have them thats fine. But I have always felt they gave the RPG more life visually, And is something i definetily want to feel when I play this.

Ok thats the end of my nitpicking. Back to work on a font editor.

Escheron · « **Reply #16 on:** April 08, 2015, 12:48:18 pm »

(Sorry for the double post)

What sort of limits should we have in regard to inventories? For instance, how many spells each character can learn, how many unique items can exist in the game's database, the number of total enemies, the number of enemy parties that can be formed, etc. I'll break down some of the figures (and estimates) I have at the moment:

There are 24 unique spells that characters can learn. Some enemies have special attacks that are formulated in the same way spells are, so those may in fact be stored in the same routines. In effect, I guess that means there are more than 24 "spells" in the game. I would put the number more around... 32 - 40?

There are 61 total items, counting all equipment types, potions and key items. I have no plans to expand that. I was thinking the party's shared item inventory would allow storage of somewhere around 28 - 32 items. Items don't have stacking quantities, so any duplicate items obtained occupy their own individual slots, as seen in the mockup screen below.

There are 26 types of enemies so far, counting bosses. This value may increase slightly. As for the specific enemy formations that can be encountered, I've come up with only a handful so far. I would think a limit of 64 types would be generous enough. I believe there are only 15 unique enemy graphics. Most are 32x32 px, but some larger foes are 64x32. (See attachment below)

There are six recruitable characters who can be swapped in and out of the party, so the save file has to remember their current stats, which spells they've learned, and which items they have equipped. Characters have four types of equipment slots, and I was thinking of limiting them to knowing up to 12 spells each. As for character statistics, maximum and current HP, MP, Attack, Defense, Magic and Agility are all base values that need to be stored in the save file. Hit and Evade are strictly derived from the character's Agility and whatever items they have equipped, so they're not exactly tied to the character in a sense that has to be stored by the save information. So, in summary, a character should look something like this:

Code: [Select]

Identifier / pointer (to indicate which character)
Flag to indicate whether or not the character is in the active party

Level (value from 1 to 256)
Experience (value from 0 to 255)

Weapon slot 1
Weapon slot 2 / Shield slot
Armor slot
Accessory slot

Spell 1
Spell 2
Spell 3
Spell 4
Spell 5
Spell 6
Spell 7
Spell 8
Spell 9
Spell 10
Spell 11
Spell 12

Maximum HP
Current HP
Maximum MP
Current MP
(Base) Attack
(Base) Defense
(Base) Magic
(Base) Agility

(There are two guest characters who are recruited during specific events, but they don't level up, and their spells and equipment can't be altered by the player. It may not be necessary for the save file to keep track of those characters' properties.)

When I say "base" values, I mean the value before it's changed by equipment. Stat bonuses that are granted by equipment don't need to be kept track of by the save file, since those bonuses can be applied through a simple look-up operation whenever the save file is loaded. i.e. The game sees that the character is wearing a specific set of equipment, and applies that equipment's values to the character's stats accordingly. The "Hit" stat is determined by looking at the character's total Agility, then adding equipment bonuses. A character has a natural +1 point of Hit for every 8 points of Agility, including Agility bonuses from equipment. Hit caps at 99. Evade is determined in a similar way, except that the character gains +1 point of Evade for every 16 points of Agility. Evade caps at 33.

The "Level" and "Experience" strings correspond to hidden statistics. Characters gain seemingly random statistical boosts after battle, but in fact, they're actually gaining experience levels. Each enemy is worth 1 experience point apiece, and the required experience to gain a level is usually a very small number between 1 and 255, depending on the character's current level. Enemies also have levels associated with them for purposes of determining whether or not characters can continue to gain experience from that enemy in the first place. i.e. When your characters reach a sufficiently high level, fighting enemies of a much lower level will forfeit any experience that would normally be gained from the battle, to prevent the player from grinding exclusively on weaker foes.

Statistical gains during level ups are determined by two factors: Growth rates native to that character, and bonus growth applied by the type of equipment the character is holding. As an example, Maya always receives +1 Mag, +1 Agi, +1 MP and +1 HP when she levels up. If she happens to be wielding a sword-type weapon at the time, then she also receives +1 Str. If she happens to be wearing a suit of heavy armor, then she also receives +1 Def and an additional +1 HP. These level ups continue until Maya's stats reach their maximum values, or she somehow advances all the way up to level 256 without having obtained max stats in the process. (Which doesn't matter, since stats can also be increased through the use of stat-boosting potions)

On another note, I decided to revise some of the menus to do away with the 4x4 font elements. They never managed to fit in quite right, and I just don't see menu labels as being a necessity to begin with. I guess the menus look a bit cleaner without them. Also, the current font is attached, including equipment icons and menu frame elements. (Note: The characters for O and 0 use the same tile)

Iambian · « **Reply #17 on:** April 09, 2015, 11:40:59 am »

Quote from: Escheron on April 08, 2015, 12:48:18 pm

[...]
What sort of limits should we have in regard to inventories? For instance, how many spells each character can learn, how many unique items can exist in the game's database, the number of total enemies, the number of enemy parties that can be formed, etc. I'll break down some of the figures (and estimates) I have at the moment:
[...]

Inventory max limit can be decided later. We're coding this such that if it needs to be changed, it can be done trivially (tho this might make save files incompatible between versions if we do it that way). Same for number of spells. For that, I'd just go with whatever would help make the game play the way you want it to.

Maximum number of unique items is generally agreed upon to be 256, but if you need 512, we can pull shenanigans for it (Lufia II for the SNES did that).

Up to 256 different encounter types per encounter zones, up to 256 encounter zones... well. 255. We're lumping monsters-in-a-box as an "encounter zone" for ease of implementation. An "encounter type" is defined here as a preselected sequence of monsters that can be encountered in an encounter zone. An "encounter zone" is an index to encounter types and is triggered via the hotspot detector in some manner.

A total of 256 different types of enemies or things that can be lumped together as an enemy object.

If we consider a spell to be similar to enemy special attacks with regards to implementation, this may make things easier. Regardless, up to 256 of them too. If you need more, shenanigans can be done.

----
As far as menu design is concerned, there are some unintuitive limits to such things as box sizes, since the menu frames are being dynamically generated via a real box routine and a pixel plotter for the white frame. The limits are mostly common-sense and probably won't be infringed upon. Either way...
Boxes must be wider than 8 pixels. Boxes must be taller than 6 pixels. All boxes must be created and contained fully on-screen.

Escheron · « **Reply #18 on:** April 09, 2015, 02:39:54 pm »

255 - 256 is definitely more than generous. None of the inventories, spells or unique enemy types or formations should even push 100, so we're in the clear there. Given the length of the game, there just aren't that many items to span out. i.e. There are few types of weapon or armor upgrades that can be bought, because there are maybe 4 distinct towns / villages you'll visit during the course of the main story, and most equipment upgrades are scattered throughout dungeons.

----

I've been working out some ideas for how shops would be implemented. Going back to my earlier suggestion, what I was thinking was that the player would walk into a building, then the player's sprite would disappear (as if they had completely entered the structure) and a welcome dialog would appear, along with the choices to buy or sell items.

The "buy" menu will consist of a small dialog box where the shopkeeper's dialogs would be displayed - things like, "What'll it be?" or "Your inventory is full!"

The lower box will display the shopkeeper's inventory (up to 4 distinct items) along with their respective prices.

For the "sell" menu, I was thinking the standard inventory screen would come up. Instead of listing sell prices beside items (due to not having enough space to maintain two columns and prices at the same time) a dialog box would be superimposed when an item is selected, and the shopkeeper would say something like, "How about 2200G?" or "No, thanks." (if the item can't be sold - e.g. if maybe it's a key item)

Geekboy1011 · « **Reply #19 on:** April 09, 2015, 03:53:07 pm »

My only groan with the walking into doors and having a menu pop up is it feels kinda cheap. We most definitely have the space to store shops and such and the screen realestate to make it look good. As for the selling items I like the idea of them saying "I can sell this for X"

In the previous Escheron thread when you proposed the item system you had it designed as such that items in dungeons would respawn and such like that. Would this iteration follow suit? ,Or is it going to be one only?

EDIT: Returned post back to original status lol

Escheron · « **Reply #20 on:** April 09, 2015, 04:17:44 pm »

Quote

My only groan with the walking into doors and having a menu pop up is it feels kinda cheap. We most definitely have the space to store shops and such and the screen realestate to make it look good. As for the selling items I like the idea of them saying "I can sell this for X"

We can do it that way. I was just thinking of ways to conserve space in the tileset. If the player has to walk into shops and explore the layout, then I'll have to create tiles for counters, decor, etc.

Quote

In the previous Escheron thread when you proposed the item system you had it designed as such that items in dungeons would respawn and such like that. Would this iteration follow suit? ,Or is it going to be one only?

Maybe both. Items such as ultimate character equipment shouldn't respawn, but in most cases, treasure chests will probably contain mundane items or quantities of gold. Maybe we can set a "do not respawn" flag for only a handful of chests that contain rare equipment or key items.

There may be an entirely easier way to do this though. Any one-time item you come across could have a "cannot drop / sell" flag, so if you try to remove it from your inventory, the game won't allow you. When you approach the chest you originally took the item from, the game could check to see if that item is already present in your inventory. If it is, then the chest will now contain something like a small quantity of gold instead. That would help reduce the number of event flags that the save file has to keep track of.

By the way, you mentioned earlier that you thought the tileset felt forced. I want to make sure every detail is just right, so are there any specific changes you would suggest? I posted a request thread here. Honestly, I'm not very good with tile work, so hopefully there's someone with more expertise who can help me put together a nice-looking tileset for the game.

Geekboy1011 · « **Reply #21 on:** April 09, 2015, 04:23:52 pm »

Loved that accidental edit, I fixed my post with its original contents. As for you being appointed moderator, Well you are one of the projects authors right

seems fitting to me!

That being said shops can be done in some kinda open floor layout if we do not want counters and such. That's something we can tinker with as time goes on.

As for items that would work and would give some re exploration reasons to dungeons other then grinding. With that part of the challenge is being able to lose that gear and having to go back and get it, That could get rather boring/worse then grinding though so will have to think of how that can be balanced I guess.

Tilesets. Yeah I am not much of an artist my self. I think my main problem with it is that its not balanced white vs negative space. And it feels rather bland/uninteresting consequently. The older set that me and iambian started with, while blockish, has a decent balance to me and is appealing to my eyes. SO its just finding a good balance

With that yeah someone with expertise with spriting would be nice.

Escheron · « **Reply #22 on:** April 09, 2015, 04:42:26 pm »

Suffice it to say, SMF's posting tools aren't very intuitive

So, about that tileset. Should the tiles mostly be dithered, or do you think a mostly white tileset with basic black outlines would look better? I mean, I could always downcode some tile rips from Final Fantasy games to B&W. The game may end up looking like an NES FF title, minus any color detail.

----

Here's how I was thinking of formatting the equipment tables in the design documentation. I'm wondering if any of the various types of special properties attached to equipment may be too complicated from a coding standpoint. For that matter, I'm wondering how many simultaneous properties can exist on a single piece of equipment.

Code: [Select]

Under "OTHER NOTES," the "ITEM" flag indicates that a piece of equipment casts a spell if selected from the item inventory
and used in that manner.


SWORDS   | AT | DF | MG | AG | HT | EV | Crit. | OTHER NOTES
—————————+————+————+————+————+————+————+———————+——————————————————————————————
Broad    | 12 | .. | .. |-05 |+60 | .. | 1/32  | ..
Mythril  | 18 | .. | .. | .. |+70 | .. | 8/32  | ..
Coral    | 20 | .. | .. |-05 |+60 | .. | 1/32  | Thunder elemental
Ice      | 22 | .. | .. |-05 |+60 | .. | 1/32  | Ice elemental
Flame    | 28 | .. | .. |-05 |+60 | .. | 1/32  | Fire elemental
Ebony    | 16 | .. | .. | .. |+60 | .. | 1/32  | Inflict Poison
Vorpal   | 32 | .. | .. |-05 |+40 | .. | 8/32  | Inflict KO
Defense  | 44 |+05 | .. |-05 |+60 |+08 | 1/32  | ITEM: Blink spell
Revenge  | ** | .. | .. |-05 |+40 | .. |  **   | (1) Revenge sword effect
Blood    | 08 | .. | .. |-05 |+20 | .. |  **   | (2) Drain effect
Ragnarok | 56 | .. |+08 |-05 |+60 | .. | 1/32  | Holy elemental
         |    |    |    |    |    |    |       | (3) Unleash Thunder spell

** The Revenge and Blood swords cannot score critical hits.

(1) The Revenge sword's damage is equal to its wielder's current / max HP
 difference, and the damage output ignores its target's Defense power.

 Potential bug foresight: Could the Revenge sword's non-conventional damage formula affect a second wind attack?

(2) The Blood sword "drains" HP from enemies. For all intents and purposes,
 this simply means the weapon heals its wielder by an amount equal to the damage that the sword inflicted against its target.
 If the target has the Undead flag, then the Blood sword's damage / heal effect is reversed.

(3) There's a 1/16 chance that physically attacking will cause this weapon to
 cast Thunder on its target immediately afterward. The spell will function at full, regular efficiency.


STAVES   | AT | DF | MG | AG | HT | EV | Crit. |  OTHER NOTES
—————————+————+————+————+————+————+————+———————+——————————————————————————————
Staff    | 06 | .. |+05 | .. |+70 | .. | 1/32  | ..
Serpent  | 10 | .. |+10 | .. |+60 | .. | 1/32  | Inflict Poison
Hades    | 14 | .. |+15 | .. |+70 | .. | 1/32  | Fire elemental
         |    |    |    |    |    |    |       | ITEM: Fire spell
Healing  | 16 | .. |+15 | .. |+70 | .. | 1/32  | ITEM: Heal spell
Lilith   | 22 | .. |+20 |+05 |+60 | .. | 1/32  | Inflict Sleep
Zeus     | 28 | .. |+25 | .. |+60 | .. | 1/32  | Thunder elemental
         |    |    |    |    |    |    |       | ITEM: Tornado spell
Seraph   | 32 |+05 |+30 | .. |+70 | .. | 1/32  | (4) HP regeneration effect

(4) At the end of each round, the staff's wielder automatically recovers 8% of
 their maximum HP, unless they are KO'd.


SHIELDS  | AT | DF | MG | AG | HT | EV | OTHER NOTES
—————————+————+————+————+————+————+————+——————————————————————————————————————
Buckler  | .. |+02 | .. |-05 | .. |+08 | ..
Large    | .. |+04 | .. |-10 | .. |+12 | ..
Ebony    | .. | .. | .. |-10 | .. |+12 | Resist Ice
Mythril  | .. |+06 | .. | .. | .. |+16 | ..
Kaiser   |+08 |+06 | .. |-10 | .. |+12 | ITEM: Berserk
Aegis    | .. |+08 | .. |-10 | .. |+24 | Resist KO
Sacri    | .. |+12 | .. |-10 | .. |+20 | Resist Poison, Sleep and KO


MAIL     | AT | DF | MG | AG | HT | EV | OTHER NOTES
—————————+————+————+————+————+————+————+——————————————————————————————————————
Plate    | .. | 16 | .. |-20 | .. |-04 | ..
Mythril  | .. | 22 | .. | .. | .. | .. | ..
Ebony    | .. | .. | .. | .. | .. | .. | ..
Flame    | .. | 24 | .. |-20 | .. |-04 | Resist Fire
         |    |    |    |    |    |    | Weak to Ice
Ice      | .. | 24 | .. |-20 | .. |-04 | Resist Ice
         |    |    |    |    |    |    | Weak to Fire
Gaia     | .. | 36 | .. |-20 | .. |-04 | Resist Poison
         |    |    |    |    |    |    | (4) HP regeneration effect
Diamond  | .. | 52 | .. |-30 | .. |-08 | Resist Lightning
Dragon   | .. | 40 | .. |-20 | .. |-04 | Resist Fire, Ice and Lightning
Mirror   | .. | 48 | .. |-20 | .. |-04 | Resist Lightning and Gravity

(4) This effect is identical to the effect already noted on the Seraph staff.


CLOTHING | AT | DF | MG | AG | HT | EV | OTHER NOTES
—————————+————+————+————+————+————+————+——————————————————————————————————————
Clothes  | .. |+05 | .. | .. | .. | .. | ..
Wizard   | .. |+08 |+10 | .. | .. | .. | ..
Blaze    | .. |+10 | .. | .. | .. | .. | Resist Fire
Power    |+12 |+12 | .. |+05 | .. | .. | ..
Mirage   | .. |+12 | .. | .. | .. |+16 | ..
Minerva  | .. |+16 |+15 |+05 | .. |+04 | Can be worn only by females
Spartan  |+08 |+20 | .. |+08 |+10 |+04 | Can be worn only by males

RINGS    | AT | DF | MG | AG | HT | EV | OTHER NOTES
—————————+————+————+————+————+————+————+——————————————————————————————————————
Bracer   | .. |+02 | .. | .. | .. |+02 | ..
Mythril  | .. |+05 | .. | .. | .. |+02 | ..
Fairy    | .. | .. |+05 | .. | .. | .. | Resist Poison and Sleep
Thief    | .. | .. | .. |+10 | .. |+02 | ..
Ebony    | .. | .. | .. | .. | .. | .. | Resist Poison and Sleep
Titan    |+10 | .. | .. |-02 | .. | .. | ..
Rune     | .. | .. |+10 | .. | .. | .. | Resist Sleep
         |    |    |    |    |    |    | ITEM: Life
Protect  | .. |+08 | .. | .. | .. |+04 | Resist KO
Cursed   |-05 |-05 |-05 |-05 | .. | .. | Weak to Fire, Ice and Lightning
Holy     |+05 |+05 |+05 |+05 | .. | .. | Resist all properties

To keep the level up system a bit more simplified, there are no longer various sets of stat gains attached to every specific item. (Iambian should know what I'm talking about) This time around, stat gains are more static, and attached to equipment types. e.g. All swords cause Attack power to increase by 1 point during level up. This will require that each item merely be categorized with a flag, such as "sword," "heavy armor," and so forth. Such flags should already exist for the sake of determining how items are fitted to equipment slots, so it won't really require any additional coding, I suppose.

chickendude · « **Reply #23 on:** April 11, 2015, 10:50:52 am »

Is there any reason you aren't using smooth(er) scrolling? I imagine everything is still aligned, but it looks like you're shifting in blocks of 8, i imagine to make scrolling easier. But now that you've gone black and white smoother scrolling shouldn't be an issue. Scrolling 2 pixels at a time would be plenty fast and look much nicer in my opinion.

Anyway, i'm really happy to see this being worked on again. And it's nice to see you back Zera/Escheron!

Iambian · « **Reply #24 on:** April 11, 2015, 11:33:55 am »

Quote from: chickendude on April 11, 2015, 10:50:52 am

Is there any reason you aren't using smooth(er) scrolling? I imagine everything is still aligned, but it looks like you're shifting in blocks of 8, i imagine to make scrolling easier. But now that you've gone black and white smoother scrolling shouldn't be an issue. Scrolling 2 pixels at a time would be plenty fast and look much nicer in my opinion.

Anyway, i'm really happy to see this being worked on again. And it's nice to see you back Zera/Escheron!

We're doing that because we wanted an engine now and an RPG is so much more than just its tilemapper. I promise I'll work on smoother scrolling later but we're trying to pull together all of what makes an RPG and RPG in a fairly quick manner. The extra bells and whistles can come later.

Geekboy1011 · « **Reply #25 on:** April 11, 2015, 11:37:04 am »

Quote from: Iambian on April 11, 2015, 11:33:55 am

Quote from: chickendude on April 11, 2015, 10:50:52 am
Is there any reason you aren't using smooth(er) scrolling? I imagine everything is still aligned, but it looks like you're shifting in blocks of 8, i imagine to make scrolling easier. But now that you've gone black and white smoother scrolling shouldn't be an issue. Scrolling 2 pixels at a time would be plenty fast and look much nicer in my opinion.

Anyway, i'm really happy to see this being worked on again. And it's nice to see you back Zera/Escheron!
We're doing that because we wanted an engine now and an RPG is so much more than just its tilemapper. I promise I'll work on smoother scrolling later but we're trying to pull together all of what makes an RPG and RPG in a fairly quick manner. The extra bells and whistles can come later.

On top of this we have some hidden plans in the works. Trust us this way is better for now

Escheron · « **Reply #26 on:** April 11, 2015, 03:37:43 pm »

Update on tileset. I'm thinking these mountain ranges may blend in better. I'm not very good at dithering though. This is an example of pretty much every type of tile that occurs on the overworld. Forests will just be any random combination of the three tree tiles I have.

TIfanx1999 · « **Reply #27 on:** April 11, 2015, 06:44:45 pm »

Quote from: Escheron on April 07, 2015, 12:37:30 pm

I found a nice tileset earlier that I think I'll incorporate into the game. The dithering works well for purely B&W detail. I would like a second opinion, though. Do you think the character sprites go well with these tiles? I didn't dither any of the sprites because I was afraid it would cause them to blend with the background too much. I figure having more pronounced white pixels will help keep the sprites apart from the background tiles.

Incidentally, this tileset seems like an improvement over the one I was using previously. Areas look much less... square?

What sort of upward limit is there on the number of tiles in the tileset, and the resolution of maps? I may be able to squeeze 128 tiles, but a limit of 256 would certainly be generous. Maps should be no greater than 128x128, but I may be able to squeeze 64x64.

The number of maps may be slightly smaller since I have a new idea for handling indoor areas such as shops. For the most part, walking into a door leading to a shop will just bring up a shop menu instead of having you explore a small room and having to walk up to the shopkeeper to initiate the shop window. Given the resolution of the screen, it's actually very difficult to create a room that has both counter space and a shopkeeper standing behind it, because part of the tiles gets cut off. I figure my approach makes a bit more sense. Some areas will still have explorable indoors though, such as taverns.

Quote from: Escheron on April 07, 2015, 12:37:30 pm

I found a nice tileset earlier that I think I'll incorporate into the game. The dithering works well for purely B&W detail. I would like a second opinion, though. Do you think the character sprites go well with these tiles? I didn't dither any of the sprites because I was afraid it would cause them to blend with the background too much. I figure having more pronounced white pixels will help keep the sprites apart from the background tiles.

Incidentally, this tileset seems like an improvement over the one I was using previously. Areas look much less... square?

What sort of upward limit is there on the number of tiles in the tileset, and the resolution of maps? I may be able to squeeze 128 tiles, but a limit of 256 would certainly be generous. Maps should be no greater than 128x128, but I may be able to squeeze 64x64.

The number of maps may be slightly smaller since I have a new idea for handling indoor areas such as shops. For the most part, walking into a door leading to a shop will just bring up a shop menu instead of having you explore a small room and having to walk up to the shopkeeper to initiate the shop window. Given the resolution of the screen, it's actually very difficult to create a room that has both counter space and a shopkeeper standing behind it, because part of the tiles gets cut off. I figure my approach makes a bit more sense. Some areas will still have explorable indoors though, such as taverns.

The first three mockups here look quite nice. However, the final one does have a few issues imo. There are a lot of sections of just white space for ground. I think I'd personally make some grass tiles or rocky terrain tiles to break up the white. Otherwise all the plain white space looks kind of overpowering. I'd also say that building in front of the Inn looks a bit odd, as if it's overlapping instead of in front of it. Just my two cents.

Escheron · « **Reply #28 on:** April 11, 2015, 09:21:37 pm »

Regarding the white tiles: Iambian actually made a similar suggestion earlier. I decided to add more patches of grass and dirt here and there. For the villages, I may cover the entire ground with grass. Actually, I'm in the process of redoing the entire tileset for villages.

I've also put together a draft of the 64x64 overworld using what I have of a tileset so far. I tried to intersperse bits of grass here and there, so I hope this doesn't leave too many white spaces. I didn't want to overdo it, but finding the right balance is difficult.

Of course, this is subject to change. Any suggestions or criticisms would be welcome. I want to ensure all the details are just right.

One thing I will note is that I plan to redo the tiles I used for the docks. They're hardly even noticeable right now.

TIfanx1999 · « **Reply #29 on:** April 11, 2015, 11:03:47 pm »

Yep, that's much better. If you apply that to the towns as well it'll be perfect!

Author Topic: "Escheron: Twilight over Ragnoth" — progress updates and discussion (Read 122907 times)

Geekboy1011

Re: Escheron: BW

Escheron

Re: Escheron: BW

Iambian

Re: Escheron: BW

Escheron

Re: Escheron: BW

Geekboy1011

Re: Escheron: BW

Escheron

Re: Escheron: BW

Geekboy1011

Re: Escheron: BW

Escheron

Re: Escheron: BW

chickendude

Re: Escheron: BW

Iambian

Re: Escheron: BW

Geekboy1011

Re: Escheron: BW

Escheron

Re: Escheron: BW

TIfanx1999

Re: Escheron: BW

Escheron

Re: Escheron: BW

TIfanx1999

Re: Escheron: BW