Getting clip navigator to not look like garbage on mobile required wrapping the video iframes using this technique and switching out the iframe that embeds the react app into the blog with the script and link tags generated by create-react-app.
Embedding the clip-navigator directly into the page required parsing the index.html that is built by create-react-app, querying for all links and scripts, and outputting them to a new file called out.html. I do this in package.js and then move the file to my jekyll
_includesfolder for generation when the blog deploys.
Finally, I moved the clip tools into their own drop-down menu and changed the hotkeys, hence the major version bump. Still some work to have mobile auto-play.
The data schema is updated to support a
typeof either YouTube or Vzaar and the player will automatically switch based on the
typeof the currently selected video.
Support for Twin Galaxies videos means I’ll be able to include a lot more videos in the bubble bobble comparison.
I’ve implemented JSON export which makes building the data Clip Navigator needs easier - an export button now exists to copy the JSON payload directly to the clipboard, rather than snooping around in browser storage to find it.
Clicking buttons also felt a bit slow when creating and removing clips, so I’ve added some more keyboard shortcuts to speed this process up:
- Z - New clip at current location
- X - Delete last clip
- Left Arrow - Scrub -5sec
- Right Arrow - Scrub +5 sec
The activity Start Stop Continue is now renamed Retrospective and allows for any section-split retrospective styles, including, but not limited to, Start Stop Continue. Upon commencing the activity, the Presenter can select section headers from a list of presets, or, enter their own custom headers. Participants will have the section names as buttons on their device when submitting responses.
Additionally the activity now saves state to localStorage, allowing presenters to export data even after closing and re-opening a lobby.
I deleted a lot of code that was used for features from the earlier version as it was hurting my brain understanding what was currently needed to run the game. I also switched out the Speed Dial for normal buttons as it was annoying to have to constantly open it.
I implemented Chad Steele’s Hotkey approach and the three buttons can be used to add commands to the players command queue.
With that, the first section of the roadmap is complete, the game is nowhere near fun, however some ideas have arisen and part 2 of the roadmap is now up.
Fist of Five is a great way to get a quick feeling on an issue amongst your team or to start off a continuous improvement catchup like a Sprint Retrospective. I’ve used this technique a few times with different teams and thought it’d be an easy addition to Digital Icebreakers.
In my implementation the presenter’s screen can toggle between a waiting for responses view and the result view. Participants are presented with the options 1-5 and can lock one in, similar to Trivia/Poll. The result view displays the audience’s selections and an average score. The Presenter can reset the activity and/or export the results to file.
I was able to reuse the participant components already in use with the Trivia/Poll features, so only needed to implement the Presenter view and the reducers. It took a bit of time to refactor some of the existing reducers for sharing and all up the change took about three hours. I still feel this is too long for a somewhat simple activity and I can possibly reduce this time by finding a way to reduce the plumbing code needed by dynamically building
I decided to thin the project down and focus more on earlier game mechanics. I’ve raised the most basic of roadmaps and begun implementation. After cleaning up a little of the existing codebase and removing features I don’t want to focus on now, I feel like I have something I can iterate on.
The canvas represents now only a player-influenced unit, and the means to direct it via commands. Only one command exists for the moment: Go Anywhere - and it does precisely that.
Start Stop Continue is a retrospective format used by teams that are looking to improve the way they operate and I’ve added a new activity to Digital Icebreakers with the same name. Some time ago I had a branch where I was extending the Idea Wall activity to have swim lanes for each category but it got super annoying attempting to squish the idea notes into the lanes at different Presenter resolutions.
The latest attempt at Start Stop Continue implementation is much simplier: Players use a similar idea entry format as Idea Wall but their submission buttons are split into Start, Stop and Continue. The presenter just displays the already categorised cards under the headings of Start, Stop and Continue using a Grid. Clear and Export menu items are available. This approach took only about an hour as opposed to the prior attempt.
The Trivia activity is now integrated with Open Trivia DB. Instead of adding your own questions, Presenters can now click Auto Questions, select the number of questions and the difficulty, and the session’s questions will be populated by Open Trivia DB.
This update was preceeded by a number of refactorings and bug fixes that took time but had little outward facing change. Upcoming work on the project is listed here.
Shorter join codes had been on my mind for some time - lobbys were joinable via a URL and their id (a guid), but joining via UI and a short code entry had been a feature requested a few times. I started the branch at the end of October thinking it would be an easy change but after a couple of sessions it still wasn’t anywhere near being completed.
Procrastination featured a lot, and over the weeks I slowly plugged away at it, but each time I made progress, some other problem revealed itself. I changed my approach twice, with the third finally revealing the path to the goal. As how things usually turn out, increased test coverage at both the unit and end-to-end levels allowed me to confidently make the change and catch bugs introduced.
To make editing questions easier in Digital Icebreakers, I’ve added Bulk Edit functionality to question editing. Clicking the Bulk Edit button on the Questions page lets a user edit questions as lines of text in the following format:
- A question starts with a dash Until the next dash, each line is an answer * The correct answer starts with an asterix - This is another question! etc
This makes editing questions far easier even in a modal dialog, but, one could also copy/paste the text easily into something like vscode for increased manipulation.
I’ve updated the Poll feature of digitalicebreakers.com to support a Trivia mode. For any questions present, selecting an answer as the correct answer will cause this new Trivia mode to be active. Once active, Trivia mode includes the following new features:
- Questions may have a correct answer configured
- Correct answer is displayed on the Presenter’s Responses view
- New scoreboard view. Points calculated based on Players selecting correct answers
- Player’s ability to answer is blocked whenever the Presenter is displaying the answer or scoreboard
- Players can now see the question on their device along with the answers
I wanted to add a feature to digitalicebreakers.com that would let the presenter randomly select a member of the audience. I came up with the idea of the audience member’s names floating around the screen and gradually fading out, leaving only the winner.
Initially I thought this would only take me an hour to implement, but a number of edge cases meant I wrote a bit more than I was expecting.
Never-the-less, it’s complete now and includes the following features:
- Audience names appear in random colours and bounce around the screen
- When the presenter selects Pick, the names that weren’t picked are faded out over five seconds, leaving only the winner
- After the five seconds, the audience’s devices update to show a green background and a winning message in the case of a win, and a red background in the case of a loss
- If the audience joins, or leaves, while the game is running, they will appear/disappear on the presenter’s screen immediately.
- The pick is cached on the backend, so if an audience member refreshes their device, it will update with their current pick status
- Refreshing an audience device changes their random cololour on the presenter’s screen
- If an audience member’s name is too long, it will appear smaller than other names on the presenter’s screen
First there was BagsOnSale but, after an amount of refactoring, now there’s also DressFwrd. Where the former is a generated edit focusing on discounted items from multiple sources, the latter is a both a single source of content and specifically international designer brand dresses only.
I hope to add another which will be specific to Australian-based dress designers, and another which will be specific to international non-discounted bag brands. At some stage I’d like to look into having the bots engage with each other…
I started playing around with hashtags on twitter.com/bagsonsale and posts there each have two hashtags, but I’ll look into expanding it the future. Also, after running for a couple of months the bot is starting to run out of content, I’ll have to find it some more sources.
I implemented a full reskin of the website view of the feed and most importantly it now works on mobile. To achieve the design I had to override the styling on strikethrough text which is not available natively. The approach I’ve used to have orange strikethrough is detailed here.
When using material-ui/makeStyles in React (JSS?) you can’t set
content: ''as it produces an invalid style. Instead wrap in quotes:
I need to build out some supporting mechanics, like a tech tree. I want to procedurally generate it, but it’s difficult with no visualisation. Instead rolling my own, I found one already existed for the graph library I’ve integrated. A couple of PRs later and I can pass my own instance of PIXI to the visualiser.
To demonstrate this I’ve passed the underlying graph that represents the garage’s floor plan to the visualiser. It also supports zooming & dragging.
I had told Meligy only last Thursday that Digital Icebreakers included front-end tests only to find out this weekend that in fact, it did not. Fixing bugs with tests by isolating logic often reduces the cognitive load it would otherwise take to fix a bug, so now there are tests.
I also solved a particularly nasty (render only) bug in recharts. I really like that library but it’s implementation is kinda like using reflection and it’s a nightmare trace.
After posting some updates on garage I realised that I often have content that sits somewhere between blogging and note taking but I don’t end up writing it because it sits in neither. The result of this is that I’ve integrated micro.blog into my site via a devlog section on the homepage.
Micro.blog takes care of twitter cross-posting and I’ve edited its theme to look similar to staffordwilliams.com. As the rest of my site is static generated, I pull the content into the homepage via RSSParser. You can see the code in the source for
I want to have people walking around the garage performing tasks, like collecting resources and building things. The player won’t have direct control of these people, but will be able to influence their priorities. I’ll need pathfinding and way to manage where things are on the screen. I’ve added nGraph to solve this which I find has a simple API that Just Works™. This also required a refactor to the drawing system so nodes could be drawn indepently from one another.
I implemented buying parts and, upon purchasing, the Orders screen is populated with the expected delivery and it’s arrival time. When the arrival time reaches zero, the parts ordered appear in the drop-off zone. The first idea of currency is implemented and the buy button is disabled when funds are not sufficient. Additionally, should a player cancel an incoming delivery, they’ll be refunded only 75% of it’s original cost.
I hit an issue in pixi.js where a single
PIXI.GraphicsI was drawing to was displaying the wrong color after a call to
beginFill. The issue was sporadic and I was unable to isolate it outside of my code in an Minimum Working Example. The workaround was to split the draws up between
A number of changes over the last couple of days increased the complexity of the project a bit. For one I hugely refactored an old shared library and converted it to a private npm package - this had no noticeable effect on the game but will either save me time in the future for this game or others. To hasten UI development I ninja’d Material-UI into the mix with a Speed Dial and animated Dialog offering the first real bit of user-interaction. I have fond memories of Street Rod and searching the local paper in that game for parts. Likewise, in garage, the player will be able to buy and sell in a similar fashion. Parts to purchase will refresh periodically and currently do so every 10 seconds for demonstration purposes. Even at this early stage, state became difficult to manage, so integrated redux, tho I’m not sure how suited it is to games.
If you didn’t guess by the url already, the game (for now) is called garage. In this game, you’ll have a garage/shed, and you’re going to make stuff in it. For a while, you’re going to need your imagination. I’ve added pixi.js to the project and rendered our first garage. You can render a new one by refreshing the page. And look what happens to the cursor when you move it over the garage…
It’s come around to that time where I feel I need to invest countless hours in writing a game again. I’m going to micro blog it as I go. It starts with create-react-app and a github workflow that will build it and push updates to S3. Here it is, it’s not much, but it had to start somewhere.