This probably needs to be a little more lightweight than the in-game GUI version of this feature

The requirements here are really limited -- we only need the player to be able to bring up a menu of combat-consumable items (ie potions)

This might not even need a "real gui" -- we can likely just use the format being used to display attacks right now, without any francy menus. That is to say, we only need floating text and an icon. Nothing fancy.

For now this just means "find a target and attack it", but will need to be extensible in the case where we want to handle healing/item usage. I'm not sure if enemies get to use items.

In combat, we are not using the collision system, as combat is 2.5D and our collision system does not support this. The only problem this creates is enitity <=> projectile collision, which needs to operate in 3d space. This can probably simply be done via distance check on a 3d sphere from the center of the entity.

Note that we CANNOT just 'fake' this system by making the damage automatic -- we want to allow for mechanics where the player "hacks" projectiles to change their behavior.

I think a control system like Rougelands would work well.

Instead of facing the direction of movement, have the player face the direction of the mouse.

This will tie in well with out-of-combat weapon swinging/interaction, which will be captured in other tasks

bug is probably somewhere in GLFW, waiting for glfw/glfw#1098 as the section of code controlling this cursor hide feature has been rewritten

Rightnow the Bootstrapper.cpp class pre-loads many scenes (menus, hexus, etc). These should be lazy-loaded so that the game can boot very quickly.

If the game crashes, this should be detected and the game should be able to quickly boot straight into the game (bypass title screen)

My guess is that this should be done via command line arguments to the game's executable (ie ./squally.exe fastboot), which the launcher should be able to pass

When the player wins in combat, the following should happen:

• Any custom events triggered (ie event that is triggered on the defeat of a boss). Be careful here, if the game crashes after the enemy dies but before this event is triggered, we don't want potential soft-locks.
• Enemy death state saved (if this is permanent)
• Items/rewards given to the user. This should probably be done while still on the combat scene.
• The killed enemy should remain dead in the overworld, with their Dead animation played on NoRepeat.
• The player should load back into the position they were in when the fight started.

Probably related to bad OSX macros

• OOP style Item inheritance class structure
• The ability to filter based on item types
• Stackables
• Equippables
• Consumables
• Combat-only consumables
• Out-of-combat-only consumables

Add an automatic watch command to run when developing that runs dev tools like python scripts when resource files are changed

I just implemented a v1.0 version of this

Any hack should be temporary. The duration needs to be configurable -- some things make sense to have long durations, other things only short durations make sense

We currently need:

• Offload hackable buttons / duration progress bars to a layer above the level at runtime. This will solve the following problems: 1) low Z-index on buttons/bars that get covered and 2) the buttons/bars currently can be rotated if the parent itself rotates, which is not ideal
• Support multiple progress bars for multiple active hacks on the same object?
• Show icons by the progress bars? The same icons in the radial menu

We need to be able to uniquely identify an object or entity

Best candidate so far is the Tiled "object ID", which is assigned to all objects.
<object id="452" name="squally" type="entity" x="1739.03" y="2719.39" width="78.7879" height="88"/>

This needs to be checked to make sure that it is resistant to file edits (ie all of the object IDs changing after a minor edit)

Need the following:

• Default keybinds
• Check keybinds instead of keycodes
• Ability to reset keybinds to default

Note: There is no intention to support controllers given the need to code in this game, which would suck with a controller.

• Reward system sucks (lootboxes are garbage)
• Enemy difficulty needs tuning based on data
• There are too many enemies

The camera should dance around, shake, and all sorts of goodness.

This should also help us nail down a good camera API for the general gameplay as well.

When an enemy throws a hand-held projectile*, the following events need to happen:

• The projectile in the animation needs to disappear. This can likely be done by setting it's opacity to 0
• An event is triggered requesting a game-object version of that projectile needs to be spawned in-game in the EXACT position/rotation/z-position of the despawned projectile to prevent visual breaks
• The projectile needs to reappear in their hand (0 => 255 opacity over n seconds)

Ideally this would be generalized to minimize the amount of entity-specific code for each projectile.

• Projectile is being used very generally here -- anything that can be thrown (an axe, torch, dynamite...)

Give the player the ability to use the item in their hand outside of combat.

This will allow us to do first-strike-advantage detection via the following steps:

• Player clicks to swing their weapon
• A collision box is enabled around the weapon
• If this strikes an opponent, the fight starts w/ a player timeline advantage
• Otherwise, the enemy gains the timeline advantage

A bit ambiguous where this belongs, as it touches several systems

This should be very very very easy for us to manage. We might not even need classical stats. Just attack and defense may be adequate.

If we really cared enough to get fancy, we can shard these types (fire attack, fire resist) sort of thing.

It isn't really clear if we want "real stats" like str and dex, it seems overkill for what we need.

InputText should be updated to support:

• Support highlighting
• Support ctrl+Z
• Support click-to-move cursor positions

This should greatly improve the UX of editing code

User Request* : running a vim emulator within the cocos text buffer.

Sometimes the map in Pointer Trace fails to load tiles, only loading the objects in the map.

When speaking to a user, this only happened after first playing Story Mode, and then switching to Pointer Trace.

If the game is freshly launched, the map loads fine.

Entities/player slide around when standing idle

Should be able to boot into the game and resume a combat encounter

We need help menus for all of the cards to give users an idea of how these cards work, and how binary operations work.

Perhaps these can be quasi-interactive to let users experiment with XOR/OR/ANDing different values

The game just needs some profiling, on lower-tier machines there are some perf issues

This is low priority as of when this issue was created

We need a symbol system to allow for users to use interesting variables in multiple places
Two options:

1. A pre-set list of symbols (mouseX, mouseY, etc) that the users can use
2. The ability to inspect data in the game and register any data as a symbol. Note that while many of these symbols will be dynamic addresses, we can always re-calculate them at runtime.
   2 Example) The player register's an enemy's X position as a symbol. In our backend we would need to track the UUID of that enemy. If that UUID currently exists, return the player's X position, otherwise the symbol is considered UNRESOLVED and returns nullptr.

Or some combination of 1 and 2 where there is a pre-set list as well as user-registerable symbols

Bad mockup:

In this mockup, the input 'sad' is being mapped to 'boy' via a simple cipher

The idea is that they can drag n' drop to build a cipher to map inputs to outputs.

The users solution is then run against a suite of inputs to determine if their solution is correct.

Some things to consider:

• How to show multiple inputs + expected outputs to the user?
• Constraints on how many components they can add? A budget perhaps? Or just leave this unbounded?
• Conditionals? Probably not
• How to display the ascii table in a non-intrusive way
• Do we want to allow for a brute force mechanic?

Line commented out for debugging

It's called UbuntuMono-Bold.ttf not UbuntuMono-B.ttf not sure about the others. How does this keep happening? do we have a rogue gitignore or something?

cocos2d: fullPathForFilename: No file found at /cc_2x2_white_image. Possible missing file.
cocos2d: fullPathForFilename: No file found at /__firePngData. Possible missing file.
cocos2d: fullPathForFilename: No file found at /__halfCircleImage. Possible missing file.
cocos2d: fullPathForFilename: No file found at /__bodyImage. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
warning: don't update it again
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
warning: don't update it again
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.
cocos2d: fullPathForFilename: No file found at Fonts\UbuntuMono-B.ttf. Possible missing file.

I think this makes some degree of sense to have a night-time Terraria-styled dark light mask over the level.

Considerations:

• This should probably be made as an opacity-mask layer drawn above the level. Either we can make it exactly the same size as the screen and calculate the opacity mask on a per-update-loop basis, or we can make it the size of the level and do the same (possible performance issues with this route)
• Should be an actual cocos node (SmartNode) rather than a post-process effect, as we will need the UI to be drawn above it.
• There likely needs to be some sort of LightSource class in the Engine/ that defines the parameters for light. These params need to be tweakable by objects that inherit from it. (ie a torch that turns on and off or pulsates)

Alternatively we can go for some sort of crazy direction-based lighting system with objects that can occlude light sources. Honestly the trade-off here seems like "a shit ton more work for barely any benefit"

There seems to be constant sprite creation/destruction in this file.

This is in the update loop and not the draw loop, so it's fairly negligible.

Even if it doesn't affect performance, it makes debugging dispose methods (removing event listeners, children, etc) annoying because they're constantly being fired.

Proposed solution:

• Create a mapping of: Sprite Path => Sprite Node
• Check if map contains the sprite node we want. Create it if it doesn't exist.
• Hide previous visible sprite node and show the new active sprite.

As the title suggests, I have no clue how this shit actually works

Google "Ori and the Blind Forest". They have cool looking colored lights. I suspect some shader work needs to be done to make these happen.

Add the ability to move from one TMX map to another.

Ideally, this would be an object of type "portal", which the user can enter by pressing "W" (or their corresponding keybind)

This just needs to have a collision box that listens for player collision events to prompt the key press.

The keybind key should appear above the player as floating text, such that the user knows they can interact with the door.

We need to write shader(s) and possibly use clipping to blend the corners of the polyline terrain together

Some sort of virtual function that gets called on all SerializableObjects that passes key/value stores of save data relevant to the object instance

Cocos has a horrible system in which scrollviews grow upwards instead of downwards. I did my best to "hide the bodies" with my ScrollPane class, but I couldn't get it entirely right.

This needs to be rewritten (actually this is fairly easy):

• Use a ClippingRectangleNode to mask content that goes outside of the ScrollPane, with a plain Node class nested inside to hold the content.
• Update CSlider and CProgressBar classes to support vertical orientation
• Use this for the vertical scroll bar
• Position the content node at the very top of the ClippingRectangle. This position can be considered 0.0f. Override addChild to calculate the lowest position of the content. This can be considered 1.0f

Now the callee just has to set the position of all children in the negatives the further down they go, but scrolling will start at the top, as expected

Squally's controls feel like underwater movement right now. It's really bad.

Also, his jump animation should cancel on collision with the ground

NavigationEvents has become a non-generalized god-class. This makes it really hard to extend and add new Scenes without having to touch 4+ different files.

This should be refactored to an interface that allows for something like:
NavigationEvents::Navigate<TitleScreen>();

NavigationEvents should then keep track of all scene instances and instantiate on the fly. This should greatly decrease game load time as well, as these are currently being loaded up-front.

The screen should fade to black before the level loading begins, ideally with a pattern

See: https://youtu.be/nZKmDAbyRpk?t=17

Before combat begins there is an animation that last < 1s where the screen goes black in a diamond shape

Not sure how to tackle this one yet -- currently the loading of the CombatMap class is done in PlatformerMap.cpp.

Doing the transition in PlatformerMap might make sense

Examples:

• Enemy perma-death
• Chests opened
• Doors unlocked

Ideally this would be a function at the SerializableObject level that abstracts out the need to know any other details other than the data being saved

The math for culling sprites is wrong in cocos2d-x

Foreground objects close to the camera do not get properly culled, and this creates a jarring effect where sprites can pop out of existence.

Basically some sort of GUI for inventory system.

We decided infini-scrolling item lists is ideal, probably also with icons to make it look less drab

The equipment menu is going to be merged with this menu. A simple symbol indicating the item is equipped is sufficient

• Asserts crash if headphones get disconnected
• Audio device changes are not respected

These had to be patched on OSX to get it to compile, but I don't think the generated assembly was valid.

The mov reg, var and mov var, reg macros seem to be broken. These need fixing/testing on OSX/Linux

Ideally the binary for Windows would have the same version number as the CMakeLists.txt

Not sure how to keep these in sync without adding additional work to our lives

These improvements are too big a time sink right now, but should be done eventually:

• Enforce unique SFX for all cards. There are a couple duplicates.
• Same goes for card FX
• SFX for failing to kill a Binary0 card in StatePlayCard.cpp
• SFX for coin flip
• Row background effects. Useful when a card (ie SHL) is played to an empty row, and we still want some sort of visual. (Idea: maybe special row backgrounds in general?)
• Add an indication if a card is "stolen" (not belonging to the original owner). There is already a flag in Card.h indicating this.
• Some form of resignation without passing twice
• Mismatch in row highlight vs board highlight style
• SFX for stealing a card
• SFX for spider card special
• SFX for 'bonus moves' card
• SFX for horde
• The ability to show cards as Bin/Dec by holding Shift/Ctrl/Cmd/etc

Edit:
Finished or obsolete:

• Put a marker over the panel of the next opponent/chapter. This helps clarify the situation where they have cleared up to the last enemy in a chapter, but have not yet defeated the last enemy
• Animated background frames. These are currently static images, it would be much cooler if they were dynamic.

Currently only the castle ground terrain is implemented

There are still many other terrain types we need:

• Snow
• Grass (several variants)
• Dirt (several variants)
• Volcanic ground
• Ruins
• Something vapor-wavey for the final level (prolly need to hire an artist at this point)

We need the ability for the game to signal hints to the camera.

For example, certain puzzles need a larger field of view, and thus it would be optimal for the camera to zoom out

My current thoughts are to place an object in the level, such that when the camera is within distance "X" of the object, it zooms out. The zoom factor can be a property on the object