Omnimaga > Escheron: Twilight over Ragnoth

"Escheron: Twilight over Ragnoth" — progress updates and discussion

<< < (4/41) > >>

Geekboy1011:
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 :P

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:
(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: ---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
--- End code ---

(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:

--- 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:
[...]

--- End quote ---

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:
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:
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page