Ludum Dare
Ludum Dare
Game Jolt
One Game a Month

Welcome to 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

You are filtering on tag 'random'. Remove Filters
Previous Page | 12 total posts | page 1 of 3 | 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.


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


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.


Magic Mobile Website Compatibility

January 31st, 2015 @ 21:39
Tags: site, html, mobile, random

I recently started working on making these pages more compatible with mobile devices. One piece of advice I found quickly was to include the following meta tag in my HTML header:

<meta name="viewport" content="width=device-width,initial-scale=1">

It took me a bit longer to figure out exactly what this seemingly magic piece of code actually means for a site being rendered in a mobile browser, and to convince myself that yes, this code can magically make your website display much better on small mobile devices - but only if your website's CSS is already set up in a nice, size-independent way.

By default, mobile browsers assume that most of the internet is not designed to display well in a very small format. For that reason, they will render webpages at a large resolution more comparable to a desktop, and force the user to zoom and pan to see the content. What this code is actually doing is informing the browser that, yes, your content is fine to be displayed in a very small window - you are promising that it will resize itself and nothing will bleed off the page. This causes the browser to disable the extra-large render, freeing users from needing to zoom or scroll content sideways. So, if you've set up all your CSS to use percentages instead of fixed positions, it should result in an instant improvement in user experience as users can now simply scroll vertically through your content.

In my case, there was one other change needed to make this site's content mostly mobile-compatible. I often use screenshot images here, and those images are usually wider than a typical phone display, so I need them to scale down if the window is smaller than they are. This was accomplished easily enough by including the following CSS in the HTML header:


Which simply instructs every img element on the page to be no wide than its parent element. Aspect ratio is preserved automatically.

There are plenty of other small UX adjustments that can be made, but now my site renders in a much more convenient format for visitors on phones.


Some Pixel Art

August 03rd, 2014 @ 20:31
Tags: art, random

Indiana Jones-themed pixel art. Maybe a game, some day?

Pixel art of a truck and workers


Previous Page | 12 total posts | page 1 of 3 | Next Page