Final touches today, added an erase all button, and changed the layout to be slightly more usable and readable on mobile. Added a separate text area for notes and for items. The format of the clock creation menu has been optimized for mobile as well. While it’s not perfect, as Stardance is wrapping up I believe it’s in a usable and polished (enough) state.

clocks iii

final touches on the clock system, you can now create them on the frontend with a set of buttons at the bottom. there are 3 preset sizes, and then a section for creating any size clock from 2 to 2019 segments. when the button is clicked, it calls a userCreateClock() function. If no name is given, it is named ClockN, where N is the number clock it would be. I changed from a grid display in the parent container to a flex, using wrapping to mimic a grid when the elements are evenly spaced. However, this is much better because unlike a grid, it reacts to the width of elements (such as when you put a long name for the clock). I also added some code that iterates over the list of keys in localStorage, and finds all the ones that are clock keys using a regex. Then, it creates the missing clocks. I also use this oppurtunity to sort the clocks, first by number of segments and then alphabetically. My goal is to eventually be able to choose the type of sort, as well as add a custom order. However, I don’t see this being super important as it’s unlikely the user will have more than 4-5 clocks going at once. I also added a small favicon I designed myself in Adobe Illustrator. the music in the devlog is Soon by Snow Patrol, would recommend.

clocks

Now, the clocks actually function, and store data in local storage. You can also create new clocks with the createClock function, which has 3 arguments. parentId is the HTML id of the parent element to put the clock into, put it as “clock-grid” normally. id is the string that clock represents. Currently, they have no prefix, which means quite a few ids (albeit unusual) such as heritage-flex cannot be used as clock names even though they aren’t clocks. I plan to add a backend prefix to clock ids later. Last is size, which is either 4,6, or 8. This is the size of the clock. The increment/decrement buttons call my buttonUpdate function, but slightly modified. They pretend to have an id one more or less than the current value, so that it goes up or down by one. It can also overflow and underflow (intentionally), which makes resetting full clocks a breeze. I hope to soon add a frontend way of adding clocks, instead of the console.

clock time

Figured I’d make this devlog now because upcoming stuff is going to be big and messy and I’ll probably forget what I’ve done here by the time I’m done that. anyway, The biggest addition today was adding a clock system. I’ve made a createClock function, that works at a very basic level. This should work for the heal clock as well as user-created clocks. It has some basic exception handling, ensuring that the size is either 4, 6, or 8 (the clock sizes in BitD). This uses some modified code for circular arrays in JS from stackoverflow (credited in the code), and a css clip-path to make the pie shape. Each pie slice is a div, and the divs are much larger than the slices. However, since they aren’t buttons, I’m not concerned about overlap. The divs are this size so that I can simply round two edges 50% and then apply a triangular clip-path on top of that. I initially experimented with using set SVGs for this, but they proved to be too much work for the benefits (deathly afraid of whatever the heck xmlns is). I also used a flex display to add some crude buttons on the side, for incrementing, decrementing, and removing the clock. Since the clocks only ever change by one or two at a time, I think this is an appropriate, human friendly input type. I also modified the radio selectors to be on top of each other, I believe that looks better. Last, I made a notes section at the bottom, which is just a resizable html <textarea> that uses the same oninput="store()" logic as my other text inputs.

Adding another gas was relatively trivial lmao. Technically I realized partway in that I was somewhat jumping the gun but eh this is okay.
I realized partway through that the fact I was tracking flow velocity is a bit sketch when multiple gases of different molar masses are interacting, so I replaced it with momentum. Pretty much heavier gases should influence lighter gases more, but lighter gases will move much faster.
The second gas is visualized as green on the shader, and is like fake O2. The only difference between the gases currently is a higher molar mass(O2 would be 16x heavier!). The only noticeable difference in how the behave at the moment is that the O2 is denser, thereby being accelerated slower and having higher momentum.

Next up should be temperature. technically the temperature of a gas should change as its pressure changes. Though the changing of temperature will also effect its pressure, so that might be a bit hard to balance. We’ll see!

flex & radios

I focused a lot today on learning how flex works in CSS. This is because I’m making multi-option menus using the radio input type, for picking a heritage and background. I still have to store the data that’s inputted, but this should be relatively easy, using my old store function whenever a radio button is clicked. I also changed the onkeydown event to oninput, which stops the last character of text-inputs from not being stored. Now, the whole string is properly stored and recalled. I also changed to a variable-width font, which makes some animations very satisfying. CSS media queries are used to change certain landscape-focused divs to vertically orient when the screen is below a minimum width, i.e. a smartphone. The style is still very crude and needs some polishing, but that will come with time

I’ve added stress and trauma tracking, and use the CSS skew-y property to make them the classic BitD diamond shape. I also found 2 fonts close to the originals on Adobe Fonts, and linked them in CSS. Next up is building a robust system for managing and creating clocks. These are like trackers that fill up over time, usually for tasks such as healing, crafting, or long-term projects in-game. Website users need to be able to create their own clocks with either 4,6, or 8 segments. I’m planning on a clip-path on top of a triangle to get a pie segment shape. I’ve also been regularly checking how the site looks on mobile, ensuring it’s accessible and usable. This is because the site will almost exclusively be used on phones.

Now, I’ve been working on the logic for having buttons to press for setting data. These are the two primary ways of storing info on Blades in the Dark (BitD as I’ll call it from now on) player sheets. I decided on logic where clicking button X sets the relevant data value to that, except for the first button when the value is already at 1. Then, it sets it to 0. The general logic is as follows:

First, I create a button array with the HTML objects to modify. Then, if the first button is clicked (array is 1-indexed for readability) and the stored value is alread 1, it sets it to 0. Finally, I update the buttons with a for loop, iterating over the array until I’ve colored the right number of buttons. The rest are colored with a darker shade. Now, I’m working on expanding this to the many different types of info in BitD, such as stress.

Using localStorage to store information submitted in input fields, so they’re persistent. This is updated with every keypress, and uses a function so that it’s easy to add more fields. I used for to iterate over every item in localStorage, and setting the inputs to their values when not null. The onkeydown event calls a function that stores the current value at the relevant key after every keypress. However, one issue has arisen where the last character typed does not get stored. I hope to fix this shortly. Next, I hope to figure out the best way to store other types of data, not just text inputs.