clintbellanger / flare Goto Github PK

I created a FileParser class to abstract handling the primitive ini-style config files.

Several classes aren't using it yet. Refactor those classes to use FileParser.

This will make future changes easy, especially once we start treating the config files as utf-8 to support full Unicode.

When starting a new game, display a New Character screen.

This will be a new GameState.

• Type your character's name (use the unicode input text gathered via InputState)
• Choose a base body type (currently the only option is Human Male)
• Choose a portrait
• Possibly show the character's sprite
• Buttons to accept, or go back to the Load Game screen

Assigning this to myself because it requires reworking lots of existing assets.

Each base body type requires the full set of weapon and armor layer renders. Also the armors need to be re-rendered without a head. Change the head into a new layer, and make a unique head layer to correspond to each player portrait.

Possible future Base Body types:

• Human Female (this will be a high priority)
• Dwarf Male
• Elf Androgynous
• Human Brute (very bulky male body type)
• or whatever makes sense in various game worlds

Allow the creation of missile powers that reflect when hitting a wall, instead of dissipating. Look for a good spot (maybe the MapCollision class?) to calculate reflection angle.

For fun, try adding a Block-based power that reflects enemy missiles back at the enemy. This could be a very fun power for melee builds vs. pesky ranged creatures.

When playing the game, hitting Escape currently goes straight to the Title without warning.

Because of the way the game is saved, any current map progress is lost.

Display a dialog that allows the player to confirm he wants to "Save and Exit to Title".

Right now all of Flare lives in the same folder. Instead it should use operating system conventions; this will make it easier to distribute in official repos.

• Allow the save folder and user configuration to be located in the user's home directory e.g. ~/.config/flare/
• Allow the static game data to be located in a central location e.g. /usr/share/games/flare/

I'm not familiar with the best way to do this (e.g. detect at runtime? or set at compile time for the target OS?). If you have experience with this, please lend your expertise.

(note: enemies already have cooldowns per power slot)

Add the option of cooldown=x to powers, where x is the number of milliseconds before that power can be used again.

This is added for balance purposes.

If a power is on cooldown, darken that power in the Action Bar (same as when you e.g. run out of potions).

Add on-hit life-steal and mana-steal options to powers and weapons.

If it makes it easier to implement, it doesn't matter if enemies get these powers (e.g. you'd have to remember which enemy spawned each hazard to assign the bonus life/mana). But if you have a very clean way of doing it, feel free.

These should probably be properties of Hazards. Check these on the Enemy::takeHit() function. Currently that function can't see the hero's StatBlock; maybe each Enemy should have a pointer to that.

It's pretty hard to explain, at least for me...
The enemy menu seem to think we almost always have an enemy under the cursor. I think it's odd, but it's not really a problem.
Sometime, this menu switches between some enemies, even if nothing is moving (even the mouse cursor). The period seem to be correlated with the enemy animation period.
But then, sometime, the game trigger an attack (with no one around) instead of just move the avatar. And then, it could quickly become a real problem.
Is this understandable? Is it just me?
Someone show me this problem two days ago. I'm always using the last git commits.

Add a notification (maybe a button glow/color, exclamation point, etc) on the gameplay menu buttons (Character, Inventory, Powers, Log) when there is something new.

Examples:

• New unspent attribute point in the Character menu
• New powers unlocked in the Powers menu
• New quest text in the Log menu

These notifications should go away when that menu is opened.

Allow some enemies to patrol along a pre-set path. When defining that creature in a map file, supply a list of patrol waypoints.

This will be easier to do if each waypoint is in line-of-sight of adjacent waypoints (until A* pathfinding is added).

Patrollers should optionally stop at each waypoint for a set amount of time.

Also, add wandering enemies. Either give a pre-set rectangular area where the creature is allowed to wander, or just let the creature move more or less randomly.

Turn on mouse-move. Hold an attack button until a creature dies; your hero immediately starts moving.

Because I'm allowing holding the mouse button for continual attacks (instead of constantly clicking), it's tricky to get mouse-move controls right.

Suggestions:

• Allow attacks to mouse lock
• When doing so, the Avatar should remember that the mouse is locked in an attack context
• Allow attacking if the mouse isn't locked OR if the mouse is locked in an attack context

That way movement won't be possible until the mouse is released and pressed again. This will work more intuitively than the current system.

Maybe, slightly refactor the Avatar mouse-move system so that mouse lock context can also be "movement". Use this to continue moving even after running into an obstacle.

Note: the mouse-movement code can be tricky, so please thoroughly test before and after.

Teleport is a power that requires targeting: you must point your cursor at the teleport destination. (Burn also works this way)

Currently if you use a Teleport Scroll from the inventory it does not work as expected (there is no cursor target so the avatar warps to 0,0).

A quick solution would be to only allow targeted powers (e.g. Teleport Scrolls) to be used from the action bar.

As part of v0.15 "Translations", FileParser will have to be updated to fully support utf-8 Unicode files.

Currently each individual creature is placed in a map file. This is a bit boring for replayability.

Allow variable creature spawns instead.

Examples:

• In this rectangular area, spawn 1-3 goblins of levels 4-5.
• In this rectangular area, spawn 4-5 cave monsters of level 3.
• In this rectangular area, spawn 0-2 monsters of levels 7-9

This will require creating lists of monsters (e.g. undead by level). How best to implement that is up to you. Obviously it would be best if these lists were created automatically. For example: add a "categories" list to enemy files that define what lists it can belong to. So a Zombie might have categories=zombie,undead,crypt,cave,forest,ruins. The engine might have to read all the enemy file once to build up the category lists but this shouldn't be a big issue.

Regular specific monsters should still be allowed (this is necessary for e.g. bosses, quest creatures).

Currently there are two similar types of events.

• NPC dialog node events
• Map area events

It should be possible to combine event handling into a single class.

The event class should do everything that the NPC dialog and the Map events currently handle. Examples:

• Check event requirements
• Alter the map
• Alter the Campaign state
• Award items, xp, currency

This will allow events to be used in more places without recreating event handling code. Also it will allow new event features to be added (cutscenes, special camera movements, NPC actions, etc).

Map events (e.g. stepping on a certain square, opening a chest) should allow hazards/powers to spawn.

Most notably, this could be used to create traps.

The tricky part of this: right now all the Powers calls assume a base StatBlock. This makes sense for Enemies and Avatars who have stats. Traps don't really have a StatBlock. The necessary info to build a StatBlock is much more than fits into an EventComponent. Maybe MapIso should have a dummy StatBlock with lots of defaults, used just when creating traps?

Make sure to not put too much trap info in the map event when it belongs in a Power. E.g. it should be easy to make a Bear Trap item that a player can place, which is a Hazard that attacks the first creature that touches it (a non-moving hazard with a long lifespan).

Currently the Log Menu has a simple tab implementation. Tabs could be useful in other menus.

Factor out the tab handling/display into a new Widget class.

Currently WidgetButton will always use the same button style.

Instead the class should allow a choice of button style. Allow the parent/owner of a WidgetButton to specify what button image to use.

Also right now the button width and height is hardcoded to match the current button image. Instead, figure out the button width/height from the loaded image. Assume the button file width is the button width, and the button file height is 4x the button height (a proper WidgetButton image will have a vertical stack of regular, hover, clicked, disabled buttons).

Then WidgetButtons could be applied in new places. For example, the MenuCharacter skill-up buttons could be replaced with proper WidgetButtons.

I have temporary (just unfinished) player portraits in game right now. Justin Nichol is working on finalized versions (colored, transparent backgrounds) for them.

Three male, three female choices to start with. More can be easily added later.

Right now a careful adventurer can easily pick off a large group of monsters by pulling one at a time.

Fix this by allowing enemies to enter combat in packs.

One simple way I can think to do this: when a creature enters combat, make that creature emit a graphic-less area hazard that targets enemies but does no damage. Nearby creatures will automatically enter combat because they think they were attacked, even if they can't see the hero.

Maybe each creature has a beacon range. So maybe zombies have a very low range, but goblin scouts have a very high range.

Maybe some creatures ignore beacons. E.g. maybe gargoyles always act alone.

Conversations with NPCs can be several screens long. Right now it isn't obvious when the NPC is finished talking, or if the NPC has more to say.

Add a button or icon to show when there is more dialog. Maybe a different one to show when conversation has ended.

Maybe it can just be an arrow, or the word "Next" or "More". It could be convenient if it's a clickable button.

Several classes currently handle animation in a clumsy direct way.

A simple animation class would be better. Each class that needs an animation will create one or more Animation objects.

• Handle image loading
• Handle animation definition file loading (a file that contains frame size, location, duration)
• Internally handle frame counts/loops
• Public function that returns the current Renderable

Store the frame duration in milliseconds in the animation definition file.

Right now the engine uses a static frame rate (currently 30fps). For now, at runtime, load the animation definition file and convert frame ms to number of frames based on the static fps set in config.txt.

This will make it easier later to convert the engine to run at a variable frame-rate. I don't want to change to variable frame-rate all at once; the game has popular support on many old devices and I want to make sure any implementation is friendly to those platforms.

Right now missileX3 (used in the Multi-Shot power) is a bit hard-coded.

Instead, improve the base "missile" power type to handle multiple missiles.

• Add a power config option for the number of missiles (default 1)
• Add a power config option for the angle between missiles (int value for degrees, default 0)

By default the missiles should shoot forward. If an odd number of missiles, one should shoot straight forward. If an even number of missiles, two missiles should shoot forward (split by the set angle).

For example, it should allow a power that shoots 8 missiles surrounding the caster (separated by 45 degrees). This would make a fun boss power.

Currently the Power type groundRay (only used by Freeze) is very hard-coded.

The concept is that instead of being a single missile animation, it creates a line of repeated animations.

Make it configurable by moving the settings into power options. Also rename it, as "groundRay" doesn't make sense (it doesn't have to be a ground-only effect). Maybe "repeater".

Create base female sprites.

• Distinct proportions
• Distinct pose/animations
• Re-create the three basic armors
• Render all held equipment

Assigning this to myself as I've already begun work on it. I'd like to have this in for v0.14.

Avatar and Enemy classes currently share a large amount of code. It would make sense to factor the common parts into a base Entity class.

NPC should probably also be refactored to be an Entity.

This should also make simple multiplayer easier to approach, as other players could be represented as Entity objects.

Decision has to be made on how to store Unicode text in memory.

• wchar_t arrays?
• Uint16 arrays?
• std::wstring?

I think SDL_ttf expects Uint16, but we can do whatever conversion necessary before display.

Various functions in UtilsParsing will have to be rewritten, or we could find existing/established functions for these.

Tons of internal strings will need to be replaced.

When in the Title, Load, New game menus there should be background music playing.

Because this music needs to persist across these game states, I think this music should be loaded in GameSwitcher and started/stopped depending on the game state.

Maybe the GameState class should have a boolean that says whether this object uses the title music or provides its own music.

A fresh clone of the current version (as of this report) compiles properly but crashes upon new game or load game.

System: Ubuntu 11.04

Currently powers which cause damage depend on the appropriate equipped weapon.

Example: if the player casts Freeze and is holding a Rod, the Freeze does damage equal to the Rod's magic damage (3-8).

Allow powers to have a damage multiplier.

Example: a Heavy Strike melee power which does 200% of melee weapon damage.

damage_multiplier should be stored as an int (default 100).

With regards to the "Merge pull request #67 from pennomi/master":

Unfortunately it does not appear possible to compile EnemyGroupManager on windows. (GNU gcc complier)
On attempting to compile the following error is reported:

C:git\flare\src\EnemyGroupManager.cpp|27|error: 'struct dirent' has no member named 'd_type'|

I had a look at the file "dirent.h", and the struct dirent definitely doesn't have a member named d_type.
I did a bit of googling and this appears to be a known cross platform issue with regards to windows.
Apparently the solution to this is to use sys/stat.h instead.
I hope the following links may prove useful:

http://www.jenkinssoftware.com/forum/index.php?topic=1609.0
http://pubs.opengroup.org/onlinepubs/7908799/xsh/sysstat.h.html
http://groups.google.com/group/comp.os.msdos.djgpp/browse_thread/thread/4becb5bcda3771ee

Latest revision (2011-06-20) compiles correctly, but when I load a game (or create a new game), the music changes to the Goblin Warrens music, but the screen stays on the load (or new character) screen, freezing the game. Perhaps this is due to a failure to switch gamestates? Or are things just not rendering properly?

Map events should be able to spawn enemies.

Most likely these enemies should be loaded at map-load time instead of at event execution time, because of massive performance savings when loading similar creatures at the same time (e.g. creatures sharing the same images/sounds).

Eventually some creatures should get a cool spawning animation. Zombies can burst from the ground. Skeletons can assemble from a pile of bones. Antlions can burrow from the ground.

(update)

As discussed in this thread, this should be implemented as a Power instead. Then, use the existing system to create power effects within map events.

Here's the list of definite tasks:

• Move category_list load to beginning of program execution, not at each group load
• (done) Change number to a range, eg. spawn 0-2 monsters, or 4-9 monsters.
• Monster rarity: Common adds 6 entries to the random pool, Uncommon adds 3, Rare adds 1, so a common creature is 6 times as likely to spawn as a rare one.
• Chance to Activate: A group may show up only some of the time, so you might get surprised by a group much larger/stronger than you are prepared for.
• (done) Refactor the random spawner to use a vector of legal spawn tiles and randomly select from that list, removing the tiles as they are used.

And the list of "to consider" tasks:

• Possibly move some more of the functionality from MapIso to EnemyGroupManager
• Also, maybe add a "category=boss" to bosses. It might be fun to have a secret "Boss Gladiatorial Arena" (unlockable after you finish the main plot) where you can enter and fight a random boss each time.

Sometimes missiles fire the opposite of the intended direction. I've only noticed this when the trajectory is x=0, the y value is inverted. From the player's point of view this happens when a missile is fired towards the top-right or bottom-left of the screen exactly along the tile angle.

The New Character menu (GameStateNew) needs text input for the character's name.

Make this a widget that works like the user would expect a text box to work:

• Click to gain focus
• Highlight box on focus
• Show cursor on focus
• Click away to release focus

A little icon could be present on all the in-game menus to close theses menus. When I show the game to some people, they stopped when they had to close inventory or character sheets, unable to find intuitively how to do. A simple cross somewhere could be nice.
On the same topic, a little help icon (maybe just a question mark?) could be more intuitive to show the help tooltip on the inventory than the gold amount.

Tiles that can obscure the player should turn semi-transparent when a player is by them. The current solution, at least in the first level, of having all potential tiles be mid-height looks odd and unsymmetrical.

Two ideas on how to accomplish this:
Having a separate layer that links a tile (or a series of tiles) to another and when a player is on that tile another is ghosted. That way a level maker can just add in the layer, of course the adds a larger burden on map-making.

Second idea is sort of the Baldur's Gate/Planescape style where a mask is placed around the player and certain tiles will be rendered with that mask area transparent.

Because the sprite heads are so small, they don't need to be a 1:1 unique match for every portrait. For example, most of the short-haired male portraits can share the same short-haired sprites.

Currently I have the variables "base" and "look", which aren't very descriptive anyway.

Change to:

• base_sprites
• head_sprites
• portrait

Also change the base_and_look.txt file to something more descriptive, like hero_visual_options.txt

Translation support should be handled by setting the language in a config file. E.g. with ISO 639-1 codes

language=en

Currently english strings are littered throughout the data files. Consider ways to separate those into translation files.

We probably want a data file tree for each language supported. Example:

• translations
  • en
    • items.txt
    • powers.txt
    • menus.txt
  • fr
    • items.txt
    • powers.txt
    • menus.txt

(etc)

Ideally we want to separate displayed text from numeric values on data files. One core items file will contain all the item stats, and each language's item file will have item names and power bonus descriptions. Dialog and quest files should be done the same way (separate the quest logic from the displayed text).

As part of the v0.15 "Translations" milestone, the font engine will go from using 7-bit ASCII bitmap font to using TTF fonts.

FontEngine should be converted (or completely rewritten) to handle TTF and Unicode.

Some functionality may be handled by SDL_ttf

Sound shouldn't be necessary to play Flare.

Currently the game quits if it can't init the sound subsystem.

Change this to gracefully degrade to play Flare without sound.

Currently several enemy animations are similar and can be combined. Example, all Skeletons use the same basic animation info; the only difference is that some animation frames have different speeds.

Consider these changes.

1. Add an animation_speed (default 100) to enemy definition files. Alter this enemy's animation speed by that percentage.
2. That might require remembering the original milliseconds per frame in the animation files.
3. Move render_size and render_offset to the animation files
4. Use one base animation file per enemy race where possible. Exceptions: goblins have two variations (some run and some hop), and antlions have two variations (regular and tiny size).

Allow items to increase base stats.

For example:

• +1 Physical
• +2 Mental
• +1 All Stats

In the current game demo this would be a very powerful bonus, so I suggest only putting it on high-level Artifacts.

In the MenuManager, dragging an icon means holding the mouse button down and releasing it.

I think it would be more friendly to touch devices if instead it was click-once to pick up and click-again to drop (or swap, if that slot already has something).

What happens when an arrow misses a creature? If the arrow is slow-moving, how does the arrow not hit the same creature the next frame?

Currently, when that arrow misses, the creature becomes immune to new hazards for 5 frames. This VERY INELEGANT method usually gives enough time for that missile to move away from the creature.

If you create a very large, very slow-moving missile it will inevitably hit the creature in its way (as it gets multiple chances to attack), messing up the Accuracy vs. Avoidance formula.

Instead, each Hazard should keep a list of the Entities it has already collided with.

Optionally, add a time-out for this collision check. Example: imagine a persistent fire that can hurt a creature multiple times if it stands in the fire. The fire Hazard could do the normal attack formula, and then set a 1000ms timer where it cannot try to attack that same entity again. After the timer is up, that Entity is removed from the Hazard's collision list and the fire can attempt to hurt the same creature again.

Right now enemy steering is dead simple: face the hero (or where you last saw the hero) and walk forward.

This actually works pretty well to create dumb creatures that charge right in.

However, many situations can be improved by adding A* pathfinding to the enemy's toolbox.

Here's how I think it should work: If the enemy has free line of movement to the hero, use the current dumb steering. If the enemy does not have free line of movement (e.g. an obstacle between the enemy and hero), use A* once to calculate a temporary path. The enemy should break away from that path as soon as it re-establishes line-of-movement to the hero.

This basically allows the engine to use very cheap dumb movement in most situations, and tap into expensive pathfinding when necessary to navigate obstacles.

Note, maybe movement modes should be a state machine. As an example, creatures could be using Pursuit (charge straight at the hero), Pathfinding (I want to pursue the hero but there are obstacles in the way), Patrolling, and Wandering.

Currently map events are all triggered by entering the event location area.

Add an option for events to be activated via mouse click.

• Use hotspot=x,y,w,h that defines the clickable rectangle, relative to the center of a tile (the location x,y)
• Use tooltip=text that displays a description of the clickable item on mouse-over of the hotspot

Currently powers have requires_mana which is a boolean option, and all current powers use 1 mana.

Change this to an int, to allow powers that can cost any amount of mana.

Check to see the required mana amount exists before using a power (this is in Avatar::logic)

Whenever an Entity takes damage (or receives healing), display the amount floating above that character.

This text can be displayed above all the map tiles, but below all the menus.

The text should probably not move with the camera? For example, on a crit the screen shakes and it would be nice if the combat text didn't shake with it. It might look weird if you deal damage and quickly move; will require testing to see what looks best.

The text should float upward slowly and disappear after a short time. Test with various parameters to make sure that the combat text is not too fast or slow.

Consider using color coding on combat damage. For example:

• white font for regular damage
• red font for crits
• green font for healing

Only display combat text if enabled (maybe default enabled, set in settings.txt).