Blog

RSS

A Different Approach to Pip-Based Bars

November 23rd, 2017 (edited November 3rd, 2022)

I've been checking out a number of different systems in Factorio while experimenting with making a factory-building game. While looking through the game's assets, I noticed an interesting health bar graphic that revealed Factorio's rather neat way of handling pip-based health bars. A pip-based bar uses filled or unfilled pips to indicate progress or health, rather than a continuous line:

Factorio health bar screenshot

The most obvious way to implement this element would be to use a number of different sprite instances, and have each of them flip between a "green" and a "grey" image as appropriate. This can be done in one draw call, if the two states are on one image, and one quad per pip. Here's the asset you would need to implement this:

Two health bar pips, one green, one grey

So I was initially confused when I saw that Factorio's health bar asset actually looked like this:

Factorio health bar with lots of green pips followed by lots of grey pips

Can you figure out how this asset might be used? My guess is that the bar is drawn as a single quad that's mapped to an appropriate part of this image using its UV coordinates. For example, if you wanted a 7-pip bar with 5 pips filled, you could map your UVs like so:

Factorio health bar asset with UV mapping illustration

This is more efficient because you only have to draw one quad. More significantly, it's simpler to implement because you only need a single sprite or entity in your engine, rather than having to create several and manage their positions. Your asset just needs to have twice as many pips as the maximum pip count you want to use.


Permalink



Persistent data in the Alexa Skills nodejs SDK

February 5th, 2017

I recently started use the Alexa Skills Kit SDK for nodejs to write an Amazon Alexa skill. I ran into one rather silly roadblock, which I will now share so others can avoid.

This SDK handles persisent data (with the same session and across sessions) by providing an attributes property on the skill handler (accessed by this.attributes). My problem was that sometimes properties I set on this object were apparently completely ignored by the next request (even if I kept the session open with an this.emit(":ask", ...) response). It is perhaps obvious in hindsight, but you must make all your changes to this.attributes before calling emit, as emit will immediately and synchronously prepare and send the response to Alexa, including the attributes you're trying to persist into the next session. But it took me quite some time to figure this out.


Permalink

Contact Listeners in box2d.js

April 20th, 2015

To implement physics in Porcupine Dogfight, I used Alon "kripken" Zakai's emscripten port of Box2D to Javascript. It was very easy to get working and almost entirely identical to the original Box2D implementation, however, it lacks documentation for some of the differences. After some experimentation and trying to read the crazy auto-generated source code, I finally figured out how to implement a Contact Listener. There are two things that are not immediately obvious: the listener must be an instance of JSContactListener, and the parameters passed in are not objects, but pseudo-pointers that need to be dereferenced with wrapPointer.

I post some sample code on Github for the benefit of anyone else who has this problem in the future.


Permalink


Previous Page
88 posts — page 4 of 18
Next Page