A basic inventory system. Several inventory slots as clickable buttons and a hand slot. Clicking on an empty inventory slot puts the item from your hand slot. Clicking on the slot again brings it back into your hand.

This should solve almost all runtime errors including segfaults.

They should follow the player while keeping a distance in their shooting range. They shoot whenever they have LoS with a slight cooldown. Obtaining LoS takes a few turns. They should stop shooting when they're out of ammo and just stand still for now since there is no reloading.

This will allow sharing stepping logic and creating corpses on death without duplicating code.

Since they're meant to be overridden, the intent must be clear to the programmers.

Basically a Thing with an ItemSlot inside of it. Take the item away (e.g. by walking on it) to keep it and destroy the Thing.

Shooting rockets out of a rifle isn't very realistic.

Things perform actions. Actions take several ticks to complete. Once an action is finished, another one can be taken. Simple enough, right?

Action examples:

• Moving in one of the four cardinal directions.
• Shooting & reloading.
• Defusing a bomb.

Weapons use clips now. Shooting drops bullet casings on the ground. Clips need to be filled with bullets. Reloading is a matter of swapping the clip inside the weapon with another one in your inventory.

Sounds very general, but here's the deal:

• Split large headers into .hpp and .tpp.
• Merge .hpp and .tpp dirs into src.
• Review bits of code that were written past 10 PM (they suck).
• Possibly resolve some TODOs in the code.

Bind keys to actions directly. This might require reworking ItemSlot selection into zero-tick actions.

Basically, lerp the camera offset into the destination tile across the entire duration of the Move action.

Big boom. Much oil. US army.

Move into a wall to open it. If you stumble upon a bomb, it explodes. Only the player can open walls; other things (bullets, enemies, etc.) just bump into them.

Thing like:

• Humanoid steps.
• Plopping bullets.
• Shooting with or without a silencer.
• Certain item interactions.

Create different amounts of noise. Depending on how far the sound propagates, it could be heard by AI units.

The sound propagation code could be intertwined with what we have so far for volume/panning.

Man's gonna cook this one up.

No reloading for now, just the basic shooting mechanics. Click on a grid tile to file a bullet at it.

For now, there are just some dummies that spawn when the game starts.

This would group flags into a single field and thus reduce clutter.

Would allow us to show this thing off on the Web.

Our formatting looks like shit. We better get it in order.

The first level starts at a 32x32 grid. Every subsequent level increases both its dimensions by 25%. If you die, you go back to level 1. If you survive through a level and defuse and/or explode all bombs, you get transported to the next level instantly.

This is a prerequisite to several things, like bullets moving in a straight line and... nothing else, really.

Add a feature for Sprites to be horizontally flipped. Makes details look more variant by randomly flipping them around and makes it easier to tell where other Humanoids are facing.

Bleep-bleep.

We most likely won't do it.
Also, Lua.

Pointer jank probably.

There isn't any purpose for a score counter yet, but we'll get there. Perhaps there will be a way to spend the points on upgrades?

Scoring examples:

• Killing an enemy grants some points.
• Blowing up a mine deducts points for being reckless.
• Defusing a bomb grants a bunch of points.

Oof.

Input needs to be processed before the frame is drawn. Stuff won't work otherwise.

An HP counter for the player and the dummies. Taking bullets in reduces it.

We could use a quadtree for this, but it isn't going to make the lookup/storage much more efficient. Minesweeper maps are really small anyways, so we'll be writing more code for nothing. Could be done later this way, but for now, a simple grid is enough.

The grid is composed of tiles. A tile can be "opened" to reveal a bomb or an enemy, if present. Tiles are destructible, and that's the whole point of the game. Empty space is considered a tile too. Large empty spaces on the map may be filled with enemies, so be careful when you reveal them!

It's probably going to be based on volume panning.

The current Sprite type is only used for sprite indices and doesn't store information about how it should be rendered. draw does support tinting, but the tint should be moved into a separate type called TintedSprite. Sprite can then be implicitly converted into TintedSprite with a full-white tint; otherwise, the tint could be specified in the constructor.

Syncing levels between multiple players isn't going to be that difficult compared to other Schwungus Software projects, so why not?

That's obvious enough. There should be a camera following the player around. Otherwise, they go off-screen real quick.

Add a rechargeable flag item that allows setting up a tile for "defusal". Once you set up a tile, your flag is unavailable until the defusal is finished. Defusing a tile opens it, places a flag on top, and starts a countdown. At the end of the countdown, the contents of the tile are revealed and you get a drop (see table below). If the flag gets destroyed during the countdown, you lose points, the flag explodes, and reveals its contents (in this exact order).