Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Escheron

Pages: 1 2 [3] 4
Although it's quite a ways off, I thought it would be worth mentioning that we do plan to produce a direct sequel to Escheron using the game game engine. I mean, we'll have a flexible game engine at our disposal, so why not use it to its full potential? I'm sure Iambian will likewise want to use the engine in future projects of his own.

I threw together an overview of the world map, for player reference. This outlines some of the game's major locations, some of which can't be reached until the party obtains a ship or airship.

(click thumbnail for full view)

I guess I should post something to keep this thread active.

I suppose it's already been mentioned, but airship travel is a feature in this game. The first leg of Maya's journey is done on foot and sea travel, which is a fairly linear trek leading up to the party obtaining an airship. Once the party is in possession of an airship, the entire world opens up, including a few new towns and side quests.

Additionally, accessing some locations requires the player to fly their airship directly into it. One example is the Dreadnought air vessel belonging to Asnoth's forces. This is one of the smaller dungeons explored by the player late into the story.

(click thumbnail for full view)

The game world itself is turning out to be quite large. There's something in the area of 5 villages and 10 or 12 dungeons, a few of which are optional areas. Resolution-wise, many maps are between 32x32 - 64x64 tiles. There are a handful of areas that are broken into more than one map.

I guess I should post an update on my end, as well.

I've been alternating mostly between map design and script / event planning, both of which are quite time consuming. I recently finished the spriteset, hence Iambian now has all the character directions and facings needed to implement full character movement in his animated GIFs above. On that note, most graphics assets are complete.

A new feature I decided to add is battle backgrounds. These are 16x32 bitmaps that are tiled behind enemy bitmaps, and in some cases, partially blended (in a non-transparent manner) with enemy sprites.

I figured this would give the battle engine more aesthetic quality.

Does the topic name change mean it has a name now? Nice!

The project has always had a title, actually. I'm not sure why it was called Escheron: BW, unless Iambian or geekboy just wanted to distinguish it from the original grayscale concept. (which is now discontinued - the B&W version of the game will be the only and definitive release) At any rate, I edited this thread's title to reflect that.

This is generally the same game through and through. Just some of the assets are different. The original world, character and story layout I had planned is more or less the same, except expanded and more detailed.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« on: April 18, 2015, 12:51:54 pm »
——Update 4/18——

Everything is progressing smoothly. I finished putting together the tileset, which incidentally consists of exactly 128 tiles. I've also finished the first major draft of the design documentation, which Iambian and geekboy have hopefully had time to review. I've designed a few of the major maps, but I'm going to hold off on any further map design until I've had a chance to discuss some technical details with Iambian regarding tile limits per map.

For the time being, I have some screenshots showing off various in-game maps and menus.

Title screen:

Map exploration and cutscenes:

Various menus:

Battle screens:

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« 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.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« 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.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« on: April 09, 2015, 04:42:26 pm »
Suffice it to say, SMF's posting tools aren't very intuitive :P

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.

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.

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

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.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« on: April 09, 2015, 04:17:44 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"

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.

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.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« 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)

Art / Request for tileset [Resolved]
« on: April 08, 2015, 09:25:42 pm »
EDIT: Closed. I've made some progress with the tileset and should be able to complete it on my own.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« 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)

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« on: April 07, 2015, 04:31:31 pm »
128x128 won't be necessary. 64x64 should be generous enough for the world map. I assume looping around maps is still possible? Only the world map needs to support this feature.

I can't foresee any instance of a single map containing more than 64 unique tiles, but the tileset itself may be just under 200 tiles total. I'll try to keep it down to 128, but I can't say just yet. I'm trying to be a little more efficient with the world map tiles. Instead of 6+ tiles used to make one forest or a series of mountains, I'm going to reuse the cave tileset to create mountain ranges (which does look a bit like the mountain tiles from early FF games) and maybe 2 or 3 tiles for forests.

A couple of other things to note: There are no animated tiles anymore, and there's no need for sprite transparency ever. With the way the water tiles are dithered, the screen's intrinsic ghosting effects will make them seem almost animated. Plus it would be awkward trying to animate dithered tiles anyway. I mean, there are so many pixels close together.

As for sprite transparency, I just don't see the need. Since everything is B&W, I'd have to draw a white halo around sprites to keep them from blending with the background, which itself leaves only 6 or 7 pixels around the sprite that end up being transparent. Besides, all of the floor tiles are mostly white, with no solid-black floors anywhere in the game.

Escheron: Twilight over Ragnoth / Re: Escheron: BW
« 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.

Pages: 1 2 [3] 4