Twitter
github
npm
Freesound.org
Ludum Dare
Ludum Dare
Game Jolt
Kongregate
One Game a Month
Youtube

Welcome to brianmacintosh.com. I'm Brian MacIntosh, and I am a game programmer in the Orange County area of Southern California. This site serves to host and distribute some of my games and my blog, below.

I have developed games and apps for the XBox 360, Windows PC, iPad, Amazon Alexa, and Windows 7 Phone. I'm particularly interesting in procedural generation, pixel art, and emergent gameplay, and I'm looking forward to developing more games with these technologies.

Blog RSS E-Mail

Previous Page | 84 total posts | page 1 of 17 | Next Page

A Different Approach to Pip-Based Bars


November 23rd, 2017 @ 3:35
Tags: random, tricks

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

Necromasser Release


March 25th, 2017 @ 15:50
Tags: necromasser, threejs, javascript

We just released a new online, in-browser game called Necromasser. Necromasser is an always-on multiplayer world where you try to build the most massive zombie horde to hit the top of the leaderboard. You can play it in your browser right now!

www.necromasser.com

Necromasser Screenshot


Permalink

Procedural Potion Icon Generator


March 08th, 2017 @ 2:35
Tags: random, javascript

Randomly inspired by a coworker, I took a weekend afternoon and made a webpage that procedurally generates 32px potion icons.

Make potions here

Sample procedural potion sheet


Permalink

Persistent data in the Alexa Skills nodejs SDK


February 05th, 2017 @ 0:59
Tags: alexa, nodejs, random

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 @ 17:49
Tags: box2d, javascript, contactlistener, emscripten

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 | 84 total posts | page 1 of 17 | Next Page