• Content count

  • Joined

  • Last visited

Community Reputation

280 Neutral

About AaronWizardstar

  • Rank
  1. Depicting attack/spell ranges before movement?

    I was doing the FFT move-or-attack system too. Going by your explanation I suppose I could make all moves undoable except for those that trigger effects like hazardous tiles and (hidden) traps. Though I'd need to keep track of whether any tiles locked out the movement undo when a player character moves. Also, a player may willfully move a character through hazardous tiles, where I'd still want some way to show the character's target ranges at the potential destination. Attacks aren't going to be undoable. I'm talking about showing what attacks a character could make after a potential movement path. I'm likely going to do something like this too. Right now during a player character's turn, moving the mouse over a tile within the character's movement range shows move path, and clicking causes the character to move. I'm thinking of making two clicks on the destination necessary for a move, once to place the move arrow and again to perform the move. In between the two clicks I can show any target ranges at the destination tile (as well as allow the planned move to be cancelled).     In the four pictures here, it's the wizard's turn and he has a magic bolt spell. Clicking on a tile inside the blue movement range shows the movement arrow. Clicking on the magic bolt button shows the target range, though you can't select targets while there's a planned movement arrow. Clicking on the end of the movement arrow does the actual move.
  2. I'm making a tactics game like Fire Emblem or Final Fantasy Tactics. So there are going to be various characters with attacks and abilities that target certain tiles around them, like "target enemies within 3 tiles". Some abilities might have an area of effect, so a fireball would be "target tile within 4 tiles, area of effect has radius of 3 tiles around target". One problem I'm trying to avoid is the player accidentally moving characters to spaces where desired targets are out of range for a given ability.   Several tactics games let you undo moves before you attack or cast a spell, so if you can't target what you want with the attack/spell you want you can undo the move and try moving somewhere else. I'm interested in having terrain with certain effects though, like fires that damage characters as they walk through them or ice floors that cause characters to slip. I don't know how terrain effects would work if moves can be undone during a character's turn. I know that the Fire Emblem games show the targetable tiles at the edges of a character's movement range highlight. This is only shown for a character's single standard attack though, whereas characters in my game will have several attacks and spells. And I'm not sure how robust that would be if I want to incorporate other things like line-of-sight or area of effect, especially for the tiles inside a character's movement range.
  3. I'm still working out how to handle my spells, so I decided to make mockups of the actual spells I'm planning and break down how they work. For context, my game looks like this. Realistically my game's actual animation will be limited and consist of shuffling actor icon sprites around. Attack "Spells" in my game are really any kind of combat ability, so I'd be counting regular attacks as a spell. Still, beyond just applying damage to the target I wanted some animation, primitive as it is.Let Y be the point halfway between the caster sprite and the target spriteOver X seconds move the caster sprite to YThis doesn't change the caster actor's true tile positionApply damage to the targetThis should be a reusable effect, handling what happens when the actor dies and such. It also takes a vector to handle the recoil bounce, in this case taking the vector from the caster to the target.Over X seconds move the caster sprite back to its original positionExplosive Bolt Everyone likes area of effect explosion spells right? This spell targets any tile within range of the caster and has an area of effect that damages all enemies within it.Show a projectile sprite moving from the caster to the target tile at a speed of X units/secondFor each "layer" of the area of effect (tiles grouped by their distance from the target)Show a spell field sprite over each layer tileFor each enemy actor on a tile in the current layerApply damage to the actorProceed to the next layer in X secondsI decided to get fancy by having the explosion spread out from the target instead of hitting every enemy inside the AOE at the same time. So when the spell is running I'll need to work out what tiles to hit at what time interval. Throw I was going to give warriors a "push" ability but decided that was boring. Now warriors will get to pick up adjacent enemies and throw them. Also, the warrior here is throwing the skeleton against a wall for extra damage... Throw actually takes two targets. One for the adjacent enemy and a second for the throw target. But lets assume I already know how to handle multiple targets for a spell and work out how the spell runs.Let A be the point halfway between the caster sprite and the target 1 actor spriteLet B be the point Bi units above the caster sprite along the Y axis. This is where the target 1 actor sprite will be after it's been picked up.Let C be the point Ci units above the caster sprite along the Y axis. This is where the caster sprite will be when it throws the target 1 actor.Let D be the point Ci units above B along the Y axis. This is where the target 1 actor sprite will be at the start of the throw.Over E seconds move the caster sprite to ASimultaneously (the caster is picking up the target 1 actor):Over F seconds (less than E) rotate the target 1 actor sprite to 90 degreesOver E seconds move the caster sprite to its original positionOver E seconds move the target 1 actor sprite to BSimultaneously (the caster is "jumping" to make the throw):Over G seconds move the caster sprite to COver G seconds move the target 1 actor sprite to DSimultaneously (the caster finally throws the target 1 actor):Over G seconds move the caster sprite to its original positionRotate the target 1 actor sprite to the angle along the vector from D to the target 2 tileStart moving the target 1 sprite to the target 2 tile with a speed of H units/secondWhen the target 1 actor sprite reaches the target 2 tileApply damage to the target 1 actorIf the target 1 actor is still aliveIf the target 2 tile is emptySet the target 1 actor's tile to the target 2 tileElseDetermine the true landing tile and make it ZRotate the target 1 sprite to 180 degrees (upside down)Over J seconds move the target 1 sprite to tile ZApply damage to the target 1 actor (again)Set the target 1 actor's tile to ZReset the target 1 actor sprite's rotationHow to implement all these I was thinking of composing my spells out of hopefully reusable "effects" because the spells themselves seem to be built from common base actions like moving an actor's sprite between two points or displaying a hit sprite. But for a lot of spells these "base" actions require information that seems like they'd have to be worked out at run time. I mean, in Throw the target enemy actor's sprite gets moved between up to four points. This makes breaking spells up into interchangeable "effects" difficult, especially if I'd want to compose spells in a visual editor. The suggestions in this thread so far has boiled down the idea that a spell's effects being able to access the spell's caster and target(s) should be enough (I'd add effects being able to access the spell's area of effect too). agleed also added a suggestion that sounded like effects could store temporary values in the main spell to be used later. With that in mind, this is how I imagine spells made from composable effects would work in my game.Spells have a caster, one or more targets, and an area of effect for each target.Spells have a list of effects. When started, a spell runs its effects sequentially.Effects themselves may have child effects. When an effect is finished it runs its children sequentially.Most effects have a time component, and may also have a speed component like for projectiles.Spells have a dictionary. Effects may read from and write to this dictionary.That means there may be special "calculator" effects for writing data needed by other effects to the spell's dictionary.Effects will typically have some kind of enum property that sets whether it manipulates or is relative to the caster or one of the targets.Here are some common effects and their settingsMoveActorSpriteMoves an actor's sprite between two positions that are relative to any combination of the caster's position and the target positions. So the start position could be set to be relative to the caster while the end position could be set to be relative to target 1, or vise versa.The actor to move is affect either the caster or one of the target actors.ShowSingleSpriteShows a single sprite over a position relative to the position of either the caster or one of the targets.ShowProjectileSpriteShows a sprite moving between two positions that are relative to any combination of the caster's position and the target positions.DamageActorDamages an actor. Set to affect one of the targets (or maybe even the caster).Then there are some more specialized effects.StoreEmptyAdjacentTileGiven either the caster or one of the targets, gets an adjacent empty tile and stores it in the spell's dictionary under "StoredTile" (key can be customized).SetActorTileToStoredTileA companion to StoreEmptyAdjacentTile. Set to affect either the caster or one of the targets, set's the actor's tile position to the value under "StoredTile" (key can be customized) in the spell's dictionary.So, the Throw spell would start something like MoveActorSprite{ actor = caster; start = [caster, (0,0)]; end = [target 1, (0, -16)] }. The step where the target 1 actor is thrown would be represented by MoveActorSprite{ actor = target(0), start = [caster, (0, 16)], end = [target(1), (0, 0)] }. If the thrown actor hits a wall, the effects StoreEmptyAdjacentTile{ tile = target(1); storekey = "StoredTile" } and SetActorTileToStoredTile{ actor = target(0); storekey = "StoredTile" } are used. Though I'm still not sure how to handle the branching logic, like checking whether the thrown actor hit a wall in the first place. Nor am I sure about how to handle the explosion spread effect in the Explosive Blast spell. I'm actually starting to wonder if I'd be better off abandoning my effect composition idea and just writing each spell in code individually.
  4. OK, so your components don't reference a character directly, but the character's ID. Nonetheless it sounds like effects are hardcoded to manipulate either the spell's current caster or the spell's current target (maybe both? or the ability to choose whether to manipulate the caster or the target?). In other words there isn't something else telling the effect what character to work on while the spell is running.
  5. State Design

    If I understand you right, you want both player entities and enemy entities to use similar states like for movement or attacking. The difficulty you're facing is that even though both types of entities would use the same set of states, the states for players would have to handle the game's input while the states for enemies would have to handle AI.   First, how similar are the player entities and enemy entities themselves? Say, are they two separate classes, two subclasses of another class, or the same class?   Second, it sounds like the states for both players and enemies deal with "input", and they only differ in where the input comes from (either game input or AI). Is it possible to wrap the game's input and enemy AI in some kind of "input source" that can be assigned to or otherwise accessed from your states? So you could reuse your states between players and enemies while setting them up with the right type of input source.
  6.  OK, so projectileFX does assume the start is the caster and the end is the target. By extension all actions are implemented such that they are aware of all the runtime data they need themselves, like a damage action would always damage the target unit or the units in the spell's area of effect? This position parameter would have to be relative to either the caster's position or the target's position though, right? You wouldn't give the action just a constant position? So in addition to a set of actions (and the locations of the caster and target, and the area of effect) spells have semi-generic storage properties the actions can write to and read from? Though I'm still wondering about the ball lightning spell. You said you'd have the set of actions that represent a single bolt repeated for the number of secondary bolts you'd want to appear. By using spell's storage properties (I assume) you'd be able to keep track of the target of one bolt to be used as the start of the next bolt. Now after the first bolt I need the secondary bolts to launch at enemies within a certain distance to the original target. I'm guessing before starting a secondary bolt I could have an action that works out the next enemy, storing its location in one of the spell's storage properties to use as the target for the next bolt? For myself, assuming I'm getting your spell storage properties idea right, I'd use a single dictionary in the spell. And if actions store values in that dictionary I could expose properties in them to control what key strings they use. OK. Similar to my earlier question to agleed, are VanishComponent, DestinationComponent, and ReappearComponent implemented to always be affecting the caster, or are they made aware of which actor they're affecting in some other way?
  7. Yeah, this was what I had in mind when I was talking about "effect components" earlier. My main question is like this: You have a projectileFX action for showing a sprite moving from one location to another. It's simple enough to set a projectileFX action's sprite and speed when designing a spell that uses it. When the spell is cast the projectileFX action also needs to know the start and end points of its sprite. Do projectileFX actions assume the start is always the spell caster while the end is always the spell target? If not, how do you give the action the correct points when the spell is running? Also, your passive ability system (basically, an action in a spell can be set to trigger another spell?) and your ideas for action trees are similar to ideas I've had for my own system, like the ball lightning spell that starts as one lightning bolt then spawns other lightning bolts. Though this gets back to my earlier question of how actions access necessary runtime information, like setting up the start and end points of the secondary lightning bolts. Also, I'm not sure my engine would be able to handle joining actions in an action tree so that'll be something I'll miss out on.
  8. Sorry, I'm still having trouble understanding how your system works and how I'd adapt it to my game.   I'm worried I put too much emphasis on the "ECS" notion. I'm not really using ECS, but since my engine represents everything as nested nodes it implies some kind of composition approach.   If it helps, my game is turn based as well as tile based.   You talked about an Entity a lot. This is the whole spell right? Or the visible part of the spell? A magic bolt basically, that applies its effect when it reaches the target? Hence you said that different effects like teleport, terrain altering, and buffs would be represented by different "damage" components?   And I was confused by your teleport spell examples. So you had an idea that the "teleport self" spell could be represented by a form of movement, though I'm unsure how such a spell would be composed while fitting in with how you seem to be doing the rest of your spells.   For instance, I was imagining a teleport spell which moves the caster to the target tile, and a wind spell which moves a target actor away from the caster. I guess the wind spell is where you'd use a "DamageTeleport" component in the spell (though, how would you set it up to make it move the target away from the caster specifically)? Maybe the teleport spell would use some kind of "DamageTeleportSelf" component?
  9. I say "area of effect" instead of "radius" since the area might not be a circle, like with a ray spell that hits multiple enemies in a line (my game is tile-based).   Does Entity represent a whole spell? I'm not sure how well I can apply this system to myself since your example seems primarily geared for projectile spells or basic damage spells. I'm trying to come up with a system that can handle several kinds of spells like teleporting spells, spells that alter terrain, ally buff spells, and so on.   I brought up ECS and my lack of such really because the engine I'm using is more like a scene tree. A Spell would be a node and effects would be child nodes. So it's not like an ECS, but composition is still present.
  10. I'm designing a spell system. While I don't have a full ECS system available, I want to use a composition-based approach as much as possible. For instance a spell's targeting and area of effect would be defined by Range components with modifier components like TargetEnemyActors or TargetNeedsLineOfSight.   What a spell does would be defined by Effect components, which determine both graphics and game state changes. So Effects would include animating a projectile from a start location to an ending location, or damaging a certain actor. Effects would likely have a time or delay value for animation, or be able to be paired in parent-to-child chains to make effects follow one another. I'm wondering though about things certain Effects could only know at runtime. At runtime a spell would know its caster, target, and area of effect, but I'm wondering if that's enough for all Effects without making the Effects themselves more complex.   Take a fireball spell. It'd have an effect for launching a fireball sprite from the caster to the target (AnimateProjectileFromCasterToTarget...?) followed by an effect for damaging the target actor (DamageTargetActor). Though if I wanted fireball to be an area of effect spell, DamageTargetActor would need to be modified to damage all actors in the spell's area of effect (...DamageActorsInAreaOfEffect?). And maybe I'd want fireball to be able to damage the caster's allies, but have another area of effect spell that only damages enemies, so now DamageTargetActor needs an extra flag.   Now imagine a Ball Lightning spell, where the caster launches a bolt at an enemy and after it hits more bolts are launched from the target enemy to other enemies. The spell would need to determine at runtime what enemies are near the target enemy. Would this be inside some other kind of Effect, that would dynamically generate extra Effects to represent the new bolts following the initial bolt? Is this even a good path to go on for my spell system?
  11. GUI layout algorithms

    In my defence, it's a strategy game I'm working on (think Advanced Wars). As I said, at minimum I'd want an easy way to arrange widgets in a row or column inside some rectangle (a row of buttons for a control panel, a column of unit names for a unit list, a row of two or more columns of text fields in a statistics screen...). The last time I manually placed widgets in a game (rather, manually computed their locations) it got pretty tedious. Widgets with manual locations might work better if I had a visual editor, at which point I might as well integrate CEGUI or something that already comes with an editor.   That said, I've been thinking about how far I could go if with proportional positions and sizes (either relative to the screen or a parent widget).
  12. The biggest reason I balk at CEGUI is its apparent reliance on its built-in renderers and resource loaders.   CEGUI gives you a set of renderers for common graphics engines, but there are few resources on how to write your own renderer like there is for, say, libRocket. And I'm hesitant to give CEGUI control over its text rendering when I already have text rendering in my game (libRocket falls a bit on this too, actually). How feasible is it to create a custom renderer, especially since I apparently only have the CEGUI::Renderer class reference to go on?   I'm also worried about CEGUI's data files and resource loading clashing with my own. CEGUI wants Imageset files, while I already have a sprite atlas system in place. CEGUI uses XML files (which requires an XML library) while all of my existing data files are YAML or scripts. How much of CEGUI's native resource loading is required for CEGUI, both for compiling and using CEGUI?
  13. GUI layout algorithms

    When thinking about positioning and sizing widgets in a GUI, I get as far as nesting widgets inside of other widgets and giving widgets a size and parent-relative position. I want to be able to easily support different resolutions and aspect ratios, so I've been thinking about automatic layouts and auto-sizing.   I'd want some widgets to automatically resize themselves to some preferred size, like labels fitting their text and containers fitting their child widgets. I'm considering auto-sized widgets the same as fixed-sized widgets, only the widget changes its own size occasionally. In addition to auto-sizing, I may want widgets that stretch with their parent in some direction. Finally I'd want container widgets that automatically position their children; at minimum I'd want a container that stacks widgets horizontally or vertically like .NET's FlowLayoutPanel, Swing's BoxLayout, or CSS3's Flexbox.   This seems to set up a bunch of layout dependencies I'm not sure how to manage. Changing a widget's size may change its parent's size, which may change its sibling widgets' sizes and its grandparent's size. And I need to make sure to handle these resizes and re-layouts in the right order (can't set a stretchable widget's size until I have the parent's current size) and make sure to not invoke any unnecessary re-layouts (a stretchable layout shouldn't cause its parent to re-layout itself when it gets resized by its parent during a re-layout).*   How is this managed. Are there any standard layout algorithms out there?   * Funnily enough, both of my hangups seem to stem from stretchable widgets.
  14. Say I'm looking for a certain kind of third-party library/framework/engine to fill some role in my game. I find a library that fits my requirements, or at the very least fits my requirements better than similar libraries. The only drawback is that the project is apparently dead. The web site hasn't been updated in years, the forums are empty, and the source repository seems inactive.   The library is open source, so it's not necessarily lost. But then I'd have the responsibility of maintaining the library myself in my own project. The alternatives are (a) using a worse but active library or (b) implementing the library functionality myself and possibly killing my project again.   How do people here feel about using libraries that aren't maintained by anyone anymore? Does it ever depend on the project and/or what the library does?
  15. When pondering my pipe dream space opera game, I looked up some things on that infamous sci-fi plot device known as faster-than-light travel. Today I learned that not only are there physical limits on actually getting past the speed of light, if you could magically outrun light you get time travel for free.   This presents several challenges to designing the setting and plot of my (admittedly theoretical) game. I'd have to figure out how an interstellar society with time travel would work. For the actual game, which would basically be an RPG/strategy hybrid akin to Heroes of Might and Magic, I'd be obliged to simulate the time travelling somehow; the time travel couldn't just be a plot device like in Chrono Trigger. Finally, there's the likelihood that the game's original sweeping tale of Jedi robots punching zombie dragons would get overshadowed by all the time travel stuff.   I'll note that the idea I had for my game is a bit unique in that it would actually be a fantasy set in space, with Harry Potter and Doctor Strange stye wizards zipping around the stars. But the ability to magically control reference frames seems a bit much.