How was day 3?

Overall, I think day 3 was quite successful. I only had 4-5 hours to work on the game, much of which I spent on stream while I worked.

Drone

We managed to bring in a core mechanic of the design: the eponymous drone!

Here we have the drone on screen (the `D`). You can press "Shift" (for now), and this toggles between yourself and the drone. Implementing that was a little challenging. Parcel is configured in this project as a turn-based/energy-based system (One of three game-loop options). it was important that, when you swap between playable characters, you don't accidentally skip a turn. There was also the question of whether or not there should be a "penalty" for switching. Ultimately, I decided to make the switch free. When you initiate a switch, we essentially just swap the two characters in the turn order, but keeping the same position. This means that there's no way to swap turns to deny the guards an opportunity to act.

The second challenge I had to overcome here was around the field-of-view. The algorithm I implemented yesterday made the assumption that it was the only instance of the algorithm running, but we actually wanted to run it twice here. One of the functions of the drone is it allows you to see more of the map. The solution was to take our shadow-casting algorithm, and make it generate an overlay of visible tiles, allowing us to collect multiple maps, and apply them simultaneously, in order to decide if a tile is visible. There's an algorithmic downside here: shadow-casting is efficient because it only visits the tiles that are visible: it stops when it reaches fully shadowed tiles. For this overlay approach to work, we first have to mark every tile as "hidden", and then apply the overlays, which means the runtime will scale up with mapsize, rather than being near constant-time. However, our maps aren't huge, and I didnt notice a significant slowdown, at least on my machine.

Drag-Drop

I like the idea of the auxillary UI existing in a collection of OS-like windows, which means that they need to be positionable. So, I implemented a drag-n-drop system, where you can move a window using it's title bar (because windows can have titles now!). It can also remember where you like to keep a window, in case you close and reopen it.

This was fun to implement, and surprisingly simple. I did discover a small bug with how DOME handles text when applied to clipping zones, so I'll have to fix that before the event ends.

Selection UI

The next major item on my implementation list involves being able to use items to manipulate the world and the guards. A good first candidate for this is a smoke grenade, which can block line of sight, and create pockets of safety. In order to do this, we need a way to choose where our grenade will be placed. I only had 40 minutes or so to work on this, but the basic selection logic is now in the game, it's just lacking the visual polish right now. The way this is implemented is by taking the "Scene" class, where the player control logic currently resides, and turning it into a finite state machine. So you can transition between the "PlayState" and the "RangeSelectorState" in order to begin selecting things, and then transition back afterwards. This approach lets us chunk together the gameplay logic without getting buried by complexity, as additional features and game modes are added.

Next

For day 4, I'd like to focus on the following:

• Guards don't respond to the drone at all, and this needs to change.
• The selection UI needs visual polish
• An inventory so we can select tools/items to use
• The smoke grenade effect itself, which means applying an effect to the environment for a time. it needs to block vision.

If I get all that done, I want to make a start on the procedural generation systems, so that maps are more interesting.