User Tag List

Results 1 to 4 of 4

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

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #2
    Floormaster Imzogelmo's Avatar
    Join Date
    Sep 2005
    Location
    Earth, currently
    Age
    45
    Posts
    387
    Mentioned
    7 Post(s)
    Tagged
    3 Thread(s)
    vBActivity - Stats
    Points
    1,464
    Level
    12
    vBActivity - Bars
    Lv. Percent
    95.51%
    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.

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