User Tag List

Results 1 to 4 of 4

Thread: Finishing up Lists/Data/Structure of ..stuff..

  1. #1
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,603
    Mentioned
    204 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,111
    Level
    32
    vBActivity - Bars
    Lv. Percent
    33.09%
    Daily Activity
    0%
    Weekly Activity
    60%
    Monthly Activity
    519.19%

    Finishing up Lists/Data/Structure of ..stuff..

    ..etc. in the code. I'd like to mostly complete these in the next two weeks so I can start integrating everything together, so the actual game logic can begin to be made.. you know, the fun part.

    So.. I was sitting down today looking at what I needed to code still and what needed changing, and what needed to be written to feed code into one another so scripts could get at all that data and instances of that data along with instances of themselves (ex; battle, party menus) without causing any bugs later on and then I realized I hadn't actually done anything... :\ I think I got distracted at some point and just started looking through keyboard music and watched a Family Guy rerun..lol

    Anyway, long story short, I came up with about half-a-dozen ways to do some things and couldn't decide which would be better... One of those indecisive days I wish I would of just written out a detailed todo list and go to "auto-pilot" so to speak. (I'm sure everyone's been there before)

    Came back to it later to work on items and all I basically did was definitively decide that:
    1) items need a spell cast id.
    2) items need an effect id.
    3) I need to add effects then.
    4) ..Wait, I need to add general animated sprite lists first.
    5) ..OK, what all needs a general list of sprites/graphics and what can be inlined (put directly into an object).
    6) ..trailed off again.

    Must be a case of the Mondays. Yeah.
    This post contains the official Gleeok™ seal of approval. Look for these and other posts in an area near you.

  2. #2
    Floormaster Imzogelmo's Avatar
    Join Date
    Sep 2005
    Location
    Earth, currently
    Age
    38
    Posts
    387
    Mentioned
    5 Post(s)
    Tagged
    3 Thread(s)
    vBActivity - Stats
    Points
    1,202
    Level
    11
    vBActivity - Bars
    Lv. Percent
    87.27%
    Daily Activity
    0%
    Weekly Activity
    60%
    Monthly Activity
    56.43%
    Quote Originally Posted by Gleeok View Post

    Came back to it later to work on items and all I basically did was definitively decide that:
    1) items need a spell cast id.
    2) items need an effect id.
    3) I need to add effects then.
    4) ..Wait, I need to add general animated sprite lists first.
    5) ..OK, what all needs a general list of sprites/graphics and what can be inlined (put directly into an object).
    6) ..trailed off again.
    1. For FF1-like mechanics, you'll need a flag to determine if it can be "used" for spellcasts, and a also a spell ID of what spell it should trigger.
    2. Effect ID-- I'm thinking by that you mean an id of a script to run when it is used? I can see a few ways that could be handled. Items generally are used to lift (or set) statuses, or add HP/MP. That could be done with a series of flags.
    However, effect ID could also be a script to use in place of the usual routines (like an alternate damage formula in the case of weapons--FF6 does this a lot). In that case, you pretty much can't make a general set of flags, so it needs a script in any case.
    3. FF1-mechanics, not necessarily, but for more flexibility and able to approximate FF6-like mechanics, yes.

    4. Yeah... that's a whole other quagmire IMO.
    5. Spell-casts (regular spells, summons, blue magic, etc.-all of them), item-usages, weapon attacks, enemy special attacks, plus if you want to have the capacity for in-battle special events, those would need their own entries too.
    6. I don't know if this is the right place to mention it, but battle animations need not be deterministic--i.e. animations have to have some buffer through which they read the mechanics side (due to various random things that the spell/attack may or may not do--obvious when you think about it, as damage numerals are an animation too--but it can also manifest in subtle ways, like a Meteo spell that randomly chooses to have some number of 'hits' that each has its own target selection and damage calculation,but all under the same umbrella animation).

    Battles will need to have some kind of memory structure to keep track of lots of variables as battle progresses--variables which should be visible to everything else in battle, like spell effects, monster AI, etc. Fundamental to that memory structure, then, will be the number of combatants. If that is established, then the arrays of data can be initialized by a battle initialization function. Data such as "combatants affected by poison", "combatants under effect of Slow", etc. For every status and quasi-status (could be several dozen of those), there has to be a battle variable for each combatant. Also, all the basic attributes for every combatant must be copied somewhere.

    THEN, there has to be some "current attack" data. Again, obvious that it must exist, but it exactly what it contains must be rather substantial as well; there's a command, attacker ID, target(s) ID(s), specific spell (if magic), elemental flags, etc.
    Last edited by Imzogelmo; 01-08-2013 at 09:04 PM.

  3. #3
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,603
    Mentioned
    204 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,111
    Level
    32
    vBActivity - Bars
    Lv. Percent
    33.09%
    Daily Activity
    0%
    Weekly Activity
    60%
    Monthly Activity
    519.19%
    OK great. That helps a bunch.
    -Items are treated like spells. (what I originally had).. (Item usages I should say)
    -Added Sprite lists for weapons, misc, and effects. (Gui sprite list?)
    -Adding SpriteSets for NPCs, Players...

    Keep em' coming.


    BattleActions are no problem. The BattleEngine will have queues for actions, events, messages, and Battles; the hard part is the GUI.
    Buffs are strange... I don't know if these should just be a list for each battler or not. For example:
    -Cast Temper on monk.(cheap ass spell)
    -atk + 10;
    -Cast temper.
    -atk + 10??? (to stack, or not to stack, that is the question)
    -Cast Dispell....
    This is one example but there are far more 'grey area' effects, like buffs that last for an amount of time (condemn, or reflect) for example. I'm sure this is very confusing in the ROM, but we don't have the limitations of memory here. The best solution would be the most extensible and easy to use.

    Also worth merit is whether or not Items in an Inventory are referencing an Item, or create their own instance of an item. There are important distinctions here;
    with 1) It is simpler, but the item is effectively read-only. You cannot create a "Item Forging" (or whatever) script. (not easily anyway)
    with 2) Can get complicated fast, and breaks most FF-style inventories unless implemented from the start.
    (I do #1 right now)

    This is why I need to finish most of the low and mid-level interface code before starting on logic. Otherwise it will turn into a mess where the higher level logical code starts having to implement all kinds of random stuff that it shouldn't even be dealing with, which leads to bugs.

    ..What else?
    This post contains the official Gleeok™ seal of approval. Look for these and other posts in an area near you.

  4. #4
    Floormaster Imzogelmo's Avatar
    Join Date
    Sep 2005
    Location
    Earth, currently
    Age
    38
    Posts
    387
    Mentioned
    5 Post(s)
    Tagged
    3 Thread(s)
    vBActivity - Stats
    Points
    1,202
    Level
    11
    vBActivity - Bars
    Lv. Percent
    87.27%
    Daily Activity
    0%
    Weekly Activity
    60%
    Monthly Activity
    56.43%
    I think it's important to distinguish the various sets of data. Take character data, for instance:

    1. There needs to be a block of constant data for initialization. These are the stats for a level 1 naked character.
    2. There is a block of data for the current "naked" character. It is the data from above plus any added boosts from level ups.
    3. There is an effective character data. This is number 2 plus any boosts (or penalties) from equipment.
    4. Finally, there is a copy of #3 that goes into battle, but can be further modified by spells, status effects, items, etc.


    Now let me explain why each one is necessary.
    (1) is just the initialization data. It is needed for a base of the character's data. This doesn't have to be stored in memory, but has to be kept separate.
    (2) is an accumulation of your stats as a result of level ups. It represents the "current" lowest common denominator. Since the 5 base stats have random chances of increase on each level up, over time, these can vary widely depending on your luck. In short, it cannot be definitely determined from level alone. This is probably what would be copied to a save file.
    (3) is needed to indicate the effect of equipment. It is calculated from (2) and the equipment data.
    (4) is needed since there are spells (and could easily be items too) that affect attributes. There are spells that lower evasion, for instance.

    Each of these transitions (1) to (2), (2) to (3), and (3) to (4) can cause you to hit a cap, either at the top end or the bottom end. [Note, (1) to (2) shouldn't, but it's best to be consistent]. As a result of this necessary clamping, all of these types of data must be kept.

    (I chose character data because it's the most complex).

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social