Brian MacIntosh (Blog)

An index of website security features

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 24 Nov 2022 15:48:18 -0600

I recently took a bit of dive into website security. As the developer of a website, of course I'd like my website to be secure, even if it doesn't handle any sensitive user data. It's also just a fun way to learn more about how the web we use every day works. I read about and implemented a number of security features that I gathered from various blogs, lists, and validation tools, and I wanted to collect them in one spot for my own reference and for anyone else who might find them useful.

I'll include a few words about what each of them do, but Google will get you all the in-depth information you need, so this is mostly intended as an index of some features that exist so you can look into them more.

Example code is in PHP.

This list is certainly not exhaustive. Here are a few other sources I referenced:

CSP (Content Security Policy)

The Content Security Policy is an HTTP header that decribes what types of media, scripts, styles, and other content your page will have on it. This allows the user's browser to block any unexpected content that may have somehow been injected by an attacker (maybe in a forum post, or via an XSS attack).

Every HTML page served should have a CSP. My workflow for adding them is to add the following maximally-restrictive CSP, load the page in a browser, check the developer console for CSP errors, and add entries to permit those things. For embedded styles or scripts, the console will report a hash you can add to the CSP.


header("Content-Security-Policy: "
	."default-src 'none';"
	."frame-ancestors 'none';"
	."base-uri 'none';"
	."form-action 'none';");

You cannot use inline styles or Javascript events with a CSP without adding the 'unsafe-inline' item, which defeats much of the purpose of having a CSP.

Mitigates: XSS, clickjacking

SSL (HTTPS)

Most other security measures can be circumvented if an attacker can intercept the communications between a user and the server (such as via ARP poisoning). Acquiring an SSL certificate and using the HTTPS protocol will allow your site to use encrypted communications, making this impossible. Many hosting providers are now providing ways to acquire free certificates

You must also redirect insecure HTTP requests to HTTPS, such as via this htaccess rule:


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Strict-Transport-Security (HSTS)

Now that your site supports HTTPS, add the Strict-Transport-Security: max-age=<expire-time> header to every file served. This directs the user's browser to only use HTTPS when connecting to your site. This performs a slightly different function than a server-side 301 redirect to HTTPS, in that the browser itself will upgrade future requests to HTTPS before ever sending them to the server.

Via htaccess:


Header set Strict-Transport-Security "max-age=31536000"

Mitigates: man-in-the-middle attacks

X-Frame-Options: deny

Add the X-Frame-Options: deny header to every HTML page served. This header instructs the browser to not permit your page to be framed on another page.

Via htaccess:


<filesMatch ".(php|html|htm)$">
	Header set X-Frame-Options "deny"
</filesMatch>

Mitigates: clickjacking

X-Content-Type-Options: nosniff

Add the X-Content-Type-Options: nosniff header to every file served. In some cases, browsers will ignore the MIME type set by the server and try to determine it by looking at the file. This can be a security risk if your site hosts user-provided files, which could have a harmless extension such as .txt but be interpretted by browsers as executable code such as Javascript.


Header set X-Content-Type-Options "nosniff"

Mitigates: MIME confusion

Remove X-Powered-By

Some web technologies, such as PHP, will identify themselves in the X-Powered-By header of responses. This could help an attacker find weaknesses in the site to attack. Remove this header from all responses.


Header unset X-Powered-By

Mitigates: fingerprinting

MySQL Prepared Statements

Always use prepared statements to make dynamic SQL queries. Forming queries by concatenating strings may allow an attacker to perform SQL injection, if user-provided data can find its way into any of the components in the query. The attacker might be able to extract private data from tables, insert malicious data, or vandalize or drop data.


$query = $connection->prepare("INSERT INTO blog (id, date, title, text) VALUES (NULL, NOW(), ?, ?)");
$query->bind_param("ss", $unsafeTitle, $unsafeText);
$query->execute();

Mitigates: SQL injection

Data sanitization

Sanitize user-provided data as necessary before using it in any context. Use a function like PHP's strip_tags for text. If you expect data to be a number or bool, run it through intval, floatval, or boolval. This will prevent an attacker from inserting malicious code into pages (XSS attack).

I like to name any user-provided variable that hasn't been thoroughly sanitized yet with the prefix "unsafe". This helps me remember that that data may need to be sanitized before being used.

This applies equally to data that was previously provided by a user and stored ("second-order attack").

Mitigates: XSS, SQL injection

Hash Passwords

Passwords on the server should always be stored as hashes; the original password should not be present on the server. This will prevent an attacker who finds a way to extract data from the server from logging in with those passwords (without cracking the hashes).

In PHP, you can generate a salted password hash like so (either offline or online depending on your needs):


$passwordHash = password_hash("PASSWORD", PASSWORD_DEFAULT);

And check it like so:


$unsafePassword = $_POST['pword'];
if (password_verify($unsafePassword, 'PASSWORD_HASH'))
{
	// Restricted code
}

Mitigates: password leakage

Restrict MySQL user privileges

Scripts generating pages should use a MySQL user that has only the privileges it needs (for example, only the SELECT privilege on tables containing public data). This will prevent an attacker who finds an injection vulnerability from using it to modify or delete data.

Mitigates: SQL injection

Files on your server are public

Even if there are no links to them, any file on your server that isn't protected by an actual access control mechanism should be considered public. Do not upload .git folders, documents containing passwords, pre-minified source, etc., or an attacker might be able to enumerate and download them. Obscurity is not security.

Mitigates: data leakage, fingerprinting

Use rel="noopener" on external links that open in new tabs

When a user follows a link that opens a new tab, older browsers may provide the new page with the window.opener property, a reference to your page's window. The target page could use this to do certain operations on your page (in particular, navigate to a different URL).

Browsers will restrict this by default since late 2018, but you can be sure it's done by providing rel="noopener" on any external target="_blank" links.


<a href="https://example.com" target="_blank" rel="noopener">Link</a>

Mitigates: phishing attacks

Subresource Integrity

If your site loads resources such as scripts or stylesheets from an external domain such as CloudFlare or Google Fonts, how do you know the provider (or an attacker) hasn't inserted something malicious into them? The answer is to add a hash of the file's expected contents to the integrity parameter on the relevant HTML tag. The browser will refuse to use the content if the hash doesn't match the file served.


<script src="https://example.com/example-framework.js"
	integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
	crossorigin>
</script>

Mitigates: supply-chain compromise

Use captchas before sending emails

This is a weird one that I learned about when it actually happened on my site. If your site accepts e-mail addresses from users, you must perform a captcha on the user before sending any mail to verify they are not a bot.

Why? If an attacker has compromised a user account on some other site (such as a bank) and intends to perform some action that might send the user an e-mail alert, they can have a bot automatically feed that user's e-mail address to any site with a form that will take it. The intent is to flood that inbox with e-mails in the hope that the user will not notice the important one. This is basically a kind of DDoS attack.

This isn't just bad for the target: it could also land your domain on a spam blacklist, which can be difficult to fix.

Google provides a free, low-friction captcha called reCAPTCHA.

Mitigates: email flooding

Serve /.well-known/security.txt

This is a simple text file on your server. It provides, at minimum, an e-mail address for security researchers to contact if they find a security problem with your site. I've received two such reports for my site that were quite helpful.


Contact: example@example.com
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Mitigates: anything a security researcher might notice

Running a laser with Marlin and the Ender 3 board

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 26 Dec 2021 19:04:39 -0600

I recently started working on building a laser cutter/engraver. I wanted to use the Ender 3 v1.1.4 board and Marlin firmware because I already had them and was familiar with them. This didn't end up being too complicated, but it did require a few unexpected changes, which I'll document here. This isn't a step-by-step, just a summary of what worked for me.

I'm not an electrical engineer. This process worked for me, but I don't know if it will work you. Electricity is dangerous. Lasers are dangerous. Wear appropriate laser eye protection before powering the board with a laser connected.

You'll need to know how to build and upload firmware to the Ender 3 board to follow this. I have a little bit of info about that here.

I started with Marlin configured to run the Ender 3 Pro as a 3D printer. It's possible to run a laser in this configuration by plugging it into FAN1, the header for the part cooling fan. This is a 24V PWM signal with a pretty low frequency that you can probably increase by uncommenting FAST_PWM_FAN. However, I wanted Marlin to actually understand that this is a laser to improve the LCD interface and make sure I'm getting anything Marlin can do to optimize the results. So the first thing I did was just take a pass through 'Configuration.h' and 'Configuration_adv.h' making the obvious changes (diffs):

Commenting/disabling the extruder axis
Disabling the heaters and temperature sensors
Disabling the status screen images except STATUS_CUTTER_ANIM
Most importantly, enabling LASER_FEATURE and LASER_POWER_INLINE

This will actually work just work as far as Marlin is concerned, but I didn't know that at this point, because Marlin is actually no longer sending the laser PWM signal to the FAN1 header. This is because it would like to use the chip's faster hardware PWM for the laser instead of the slower software PWM it uses for the fan. Instead, it's actually moved the X stepper to the E stepper header, and it's sending the laser signals to the X stepper driver. For more info on this, see the bottom of 'pins_SANGUINOLOLU_11.h'.

Unfortunately we can't pick those signals up from the X stepper header because there's a stepper driver between the header and the board, and we can't easily remove the driver on this board (unlike some other boards that have socketed drivers). We have to follow the traces and find another spot on the PCB to pick it up. The laser PWM is configured in 'pins_SANGUINOLOLU_11.h' to come from pin 16 (PD7) on the microcontroller. I used the microcontroller datasheet to locate that pin, then used the PCB images from GitHub to follow the trace. I highlighted the trace in green below, and chose the via marked in red as the best place to insert a wire.

Power up the board with just the LCD attached and use a voltmeter to test the voltage between the via and ground with the laser on and off to make sure you have the right one. I cut the end off a female Dupont connector (28 AWG) and soldered it through the via.

I'm using a 24V laser, so I'm giving it 24V from the FAN1 header. I commented the FAN_PIN definitions from Marlin in order to get an always-on 24V from the fan headers. You could probably pick up 5V from an unused two-pin header or 12V from the bed terminals if that's what your laser requires.

I tested the laser using this wiring, and it was on when enabled, off when disabled, and respected the configured power output percentage, so I think the electronic configuration is good to go.

Unity UI Gradient Shader v2

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 04 Mar 2021 13:06:17 -0600

Some time ago, I shared a Unity shader for coloring a Unity UI element with a 2D gradient. That post seems to get a lot of traffic, so I thought I should share my improved version as well.

The original shader uses the first UV channel to distribute the gradient color, which means it only works well with the Simple image type. The other Image types do funny things with that UV channel. To solve this, I created a special version of the Image component that also produces a second UV channel. The second channel is always evenly distributed over the entire image, regardless of the Image Type.

Get the new component and shader here on GitHib. My shader and modifications are free to use, but the Image source code is subject to the Unity Reference-Only License.

Future work could add support for the Tiled and Filled image types as well.

Troubleshooting Ender 3 Pro Firmware Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 06 Feb 2021 15:35:37 -0600

I recently installed Marlin firmware on my 3D printer (an Ender 3 Pro, 1.1.4 mainboard) so I could increase the size of the build space. You can find several step-by-step guides on how to do this online, and I used this one from Howchoo. It was, on the whole, very helpful, but I had to troubleshoot several unexpected issues along the way (and you should definitely expect to, also). I'm documenting them for anyone else who wants to follow the linked guide with an Ender 3 Pro. I was using a Windows 10 computer.

Wiring the Arduino (Howchoo step 5): don't forget to wire the Reset pin on the printer board to the ~10 pin on the Arduino. This isn't super clearly depicted in the pictures. If you don't do this, you'll see an error like this when burning the bootloader:

avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

Error while burning bootloader.

Compiling Marlin (Howchoo step 8): when I did this, the current version of the Arduino IDE was incapable of linking the current version of Marlin. This was because it was attempting to make a long shell call to the linker that exceeded Windows' maximum length. You'll see the following error message in the Arduino IDE after clicking "Verify" or "Upload" if this happens:

fork/exec C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-gcc.exe: The filename or extension is too long.
Error compiling for board Sanguino.

As the call was largely using relative paths, I saw no way to easily reduce its length. Fortunately, there are plenty of other ways to compile and upload firmware (all of them are essentially wrappers around a compiler such as gcc and the uploader, avrdude, by the way), so at this point, I ditched Arduino and switched to following this guide from Marlin using Visual Studio Code.

PlatformIO Environment (Marlin step 2): the default_envs for the Ender 3 Pro in this configuration is melzi_optiboot. If you get this wrong you might see a series of errors like this on upload (the trailing hex value will vary):

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

Uploading firmware (Marlin step 2 [okay, like this entire tutorial is in step 2]): If you haven't (successfully) connected your printer to a computer via USB before, you might need to install drivers. If that's the case, you won't see the Ender in Device Manager (under Ports) or under the Arduino IDE's Ports list. PlatformIO might give you an error like this on upload:

Error: Please specify upload_port for environment or use global --upload-port option.

All the Ender 3 Pro boards use the CH340 drivers, which you can find here. Always restart your computer after installing drivers.

Ludum Dare 46 - The Wrecker

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 28 Apr 2020 02:45:46 -0500

It's been a few Ludum Dares since I participated, but last weekend I jumped in for the Ludum Dare 46 with audio designer Christian Camargo. This Dare saw a big spike in participation this time around, probably due to the stay-at-home orders in many places. The theme was "Keep it Alive". We worked in Unity with Wwise.

After starting, as always, by spamming a heap of ideas out on (virtual) paper, I started trying to mash two or more of the ideas together into a hybrid idea. "The Wrecker" was born from the union of a game about a factory poisoning a town, and my recent playthrough of Red Faction: Guerrilla and love for its granular destruction systems. We also grabbed two other elements from the doc we wanted to include: a time limit to push the player forward, and the idea that the player is also dying and needs to prioritize their own health against that of the town. That more than was enough to get started!

What We Learned

Wwise

The decision to use Wwise for our audio had some pros and cons. Despite being relatively unfamiliar with it as the programmer of the team, I was able to hook in pretty easily by making a single call to posting a string-named event when audio cues should be played or stopped. Christian was able to do a lot of customization in Wwise, such as randomizing the sounds played and their parameters, that I didn't need to implement.

On the down side, however, Wwise did not play nicely with Unity's Collab source control, which only synchronizes the Unity project data and did not understand that there was also a Wwise project to synchronize. This effectively siloed off the audio work until we manually transfered the project, and I didn't hear most of the audio until a few hours before the deadline. Theoretically, Wwise is capable of building audio banks into the project that could be synced, but in the jam crunch we never got that working.

I also discovered late on Saturday (making an early test build to catch any build problems - I definitely recommend it) that WWise is not compatible with Unity WebGL builds, which are the optimal way to get Ludum Dare raters into the game quickly. Fortunately this does not appear to be affecting our ability to get ratings.

Physics Gameplay

I chose to implement the game's progression through three different weapons, each capable of breaking more objects than the last, and only the final weapon was able to break through the doors into the factory. It's a pretty time-honored design. However, I opted to implement the destruction with Unity's breakable physics joint system, in which each joint has a specified Break Force.

This was a quick way to get everything up and running, but the result was a huge number of breakable joints scattered throughout the game's prefabs, many of which needed to be carefully balanced so they were only breakable by the appropriate weapon. Any change to physics parameters, such as the player's movement speed or weapon swing speed, could throw off everything. If I did this over, I would probably try to implement explicit, hard limitations on which objects can be broken by which weapons rather than relying on the implicit interactions of the physics engine to gate crit-path gameplay.

Vector Graphics

I used Adobe Illustrator to produce all the art for the game. This was very efficient, and I was able to turn out assets incredibly quickly and get back to coding. I made all the assets on two artboards (Game and UI), which made it quick and easy to ensure everything was at a consistent scale and stroke width. I used a simple visual language that I think contributes significantly to the game's clean look - collidable objects have a black stroke and background objects have none. Additionally, control prompts are always a key in a rounded white rectangle.

If you haven't check out the game yet, you can download it for free from this link, or watch a video right over here! If you are a Ludum Dare participant, you can rate the game at its Ludum Dare page.

How I make infinite procedural swords

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 26 Jan 2020 20:21:39 -0600

If you haven't seen my procedural sword generator, you can check it out at that link.

This is a custom algorithm written specifically to produce swords - not using any kind of generic machine-learning. I'm pretty happy with the amount of variety it can produce - each piece (the blade shape, the crossguard, the hilt, and the pommel) is generated from scratch from a variety of randomized parameters. So how does it work?

Process Note

I usually start a procgen project by trying to draw the thing I'm making by hand. This helps me analyze how it's made - in particular, how colors combine and where shadows and highlights go. After a quick web search for "pixel art sword" and some experimentation and iteration, I came up with this:

Pretty basic, but it helped me figure out how to color the blade (a key part of the art I was unsure about) with a light half and a dark half, a gradient that starts dark at the hilt and runs up the blade, and a rim of very light pixels to hint at "sharpness".

The Algorithm

You can follow along in the Javascript source code (drawRandomBlade function) if you'd like to see more implementation details.

Off the top, I randomize and calculate a bunch of values within ranges I set (and tweaked over time), such as:

The pommel, hilt, crossguard, and blade lengths
The blade's start width and taper
The blade's chance to acquire a "jog" or a "curve", and the max magnitude of those
Parameters for a cosine wave that can vary the blade's width

Next, I generate the shape of the blade. I start where the top of the crossguard is going to be with a forward angle of 45 degrees, then step forward one pixel at a time. Each time, I push the point into an array, along with some metadata like the current direction, how far along the blade it is, and the width at that point (which can vary based on the cosine wave I mentioned before). After recording the point, I randomly check to see if the blade should "jog", making a sharp angle, or acquire a curve. Then, move on to the next point.

Now I actually render the blade. Walking along the control points drawing segments is intuitive, but it seemed tricky to make sure the space between each segment gets filled in properly. So instead, I actually iterate over every pixel in the image. I determine which control point is closest to that pixel, then check the distance to it. If it's within the blade's radius, we'll draw it.

Color: here's how I decide what color a blade pixel will be:

In the point metadata, I previously saved a normal vector that points to the "left" of the control point. I can do a dot product between that and the vector between the pixel and the control point to figure out if it's on the left or right side of the blade. I pick the light color or the dark color based on that.
Darken the color based on how far along the blade the control point is (another value I stored in the metadata).
If the pixel is very close to the edge of the blade (i.e. the distance between it and the control point is close to the blade width), I blend in the very light "edge" color.

For most of these operations, I'm using linear interpolation to blend two different colors together.

It's not the same sword, sorry, I don't have seeding yet.

Next, it's on to the hilt. This is much simpler: I generate another cosine wave to control the lines of the grip, a width, and a color. When randomizing colors, I usually work in HSV and convert to RGB before drawing because I'm not so interested in controlling how red or green or blue the color is, but I'm much more interesting in controlling how bright (V) and how colorful (S) it is. In this case I make sure the color has a high V so it has room to get darker to make shadows.

Then I just walk along the hilt drawing slices. There is some rounding trickery to make sure I get all the pixels filled in nicely. The color of each pixel is based on the value of a cosine wave, and darkened somewhat toward the right side.

Now the crossguard. The process for this is nearly the same as that for the blade - just in a different direction. I generate two different curves for the left and right parts, but with a high probability I just discard one of them and use the other, mirrored.

Finally, the pommel. I was getting itchy to share my work at this point, so I didn't do too much here. Just generate a random radius, and draw a circle in the same color as the crossguard that's shaded darker to the bottom-right and lighter to the top-left.

Oh, and the black border is added here at the very end. Any pixel that's empty or at the edge of the canvas, and orthogonally adjacent to a filled pixel, gets filled in black.

I hope that gives you some interesting ideas! Since you made it through all that, here's a gif of the process:

Infinite Sword and Blade Sprites

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 25 Jan 2020 23:40:59 -0600

A few years ago, I made a web app that generated unlimited procedural potion icons. I've just expanded that with a new module that generates swords (well...bladed weapons, anyway). Generated icons are free for your use!

Icon Machine

No BeginPlay calls in Unreal 4? Here's why.

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 22 Dec 2019 12:41:51 -0600

Here's a strange and difficult-to-track-down bug that happened to me, so I wanted to share the solution in case someone else who needs it might find it. You're working in Unreal and suddenly none of your actors are receiving BeginPlay. This breaks your game.

If you search for this, you'll find a lot of people who overrode BeginPlay and forgot to include a call to Super (C++) or Parent (Blueprints). That will cause the BeginPlays of that object's parents to not be called, and is definitely a common and subtle bug. But what if it's happening to all your actors, even ones that have no inheriting children?

I only found this in a single YouTube video, which fortunately had the answer - when creating custom Game States or Game Modes, you must consistently inherit from AGameStateBase and AGameModeBase or AGameState and AGameMode. You can't mix and match them, or you will break the code that calls BeginPlay, which lives in the game mode.

Which should you use? According to the header, AGameState and AGameMode are intended for use with match-based multiplayer games. So if you're making one of those, use them, otherwise, use the Base ones.

Periodic Deliveries Postmortem - Time-Saving Tricks

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 09 Dec 2019 00:21:55 -0600

I'm releasing a Unity 2018 game called Periodic Deliveries! Development of any game is fraught with little speedbump tasks that slowly soak up dev time and make it a little less fun, too. Here are a few tricks I did to knock out some of those bumps in my process that you can easily implement in your Unity projects, too.

Use the MenuItem attribute to create developer cheats

In a larger game with a larger team, you might implement a developer console you can activate with a key press and type commands into. That will scale well if you have a lot of commands, and it will work in standalone builds. But if your game is small, this is a quick and effective approach. Quick implementation is important because it will encourage you to add cheats more often, and those will save you time as development goes on.

I put them all in a static class called CheatCommands. Don't forget to add a validation function, which will disable the option when it doesn't make sense and improve your own experience.


public static class CheatCommands
{
	[MenuItem("Cheats/Infinity Money", true)]
	public static bool ValidateInfinityMoney()
	{
		// Disables the item in Edit Mode and in the Main Menu
		return InGameManager.Instance.PlayerCompany != null;
	}

	[MenuItem("Cheats/Infinity Money")]
	public static void InfinityMoney()
	{
		InGameManager.Instance.PlayerCompany.AddMoney(PeriodicInt.PositiveInfinity);
	}
	
	...
}

Make custom property drawers for structs that show up in the Inspector

Using Serializable structs for common data patterns can help you avoid writing similar code multiple times. But you'll have to expand a foldout every time you want to edit this data in the Inspector. If you can write a custom property drawer quickly, you can save yourself a lot of clicks over the entire development of your project.

Here is a base class for a common property drawer I used several times. You can inherit from it to create a custom property drawer for any struct that represents a "quantity" of a "thing" (like a stack of items in a loot container, or an ingredient requirement in a recipe).


using UnityEditor;
using UnityEngine;

// Author: Brian MacIntosh (The Periodic Group)
// MIT License

/// <summary>
/// Base class that can be extended to quickly create a property drawer for a structure containing
/// data like "quantity" of "thing".
/// </summary>
public abstract class ItemQuantityPropertyDrawer : PropertyDrawer
{
	/// <summary>
	/// Name of the quantity/stack size property.
	/// </summary>
	public abstract string QuantityPropName { get; }

	/// <summary>
	/// Name of the item/object property.
	/// </summary>
	public abstract string ItemPropName { get; }

	public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
	{
		EditorGUI.BeginProperty(position, label, property);

		position = EditorGUI.PrefixLabel(position, GUIUtility.GetControlID(FocusType.Passive), label);

		int indent = EditorGUI.indentLevel;
		EditorGUI.indentLevel = 0;

		Rect quantityPosition = position;
		quantityPosition.width = 40f;
		Rect resourcePosition = position;
		resourcePosition.xMin += quantityPosition.width + 4f;
		EditorGUI.PropertyField(quantityPosition, property.FindPropertyRelative(QuantityPropName), GUIContent.none);
		EditorGUI.PropertyField(resourcePosition, property.FindPropertyRelative(ItemPropName), GUIContent.none);

		EditorGUI.indentLevel = indent;

		EditorGUI.EndProperty();
	}
}

Alternatively, get it from Github.

Here's an example use:


//RecipeComponent.cs

[Serializable]
public class RecipeComponent
{
	[Tooltip("The resource.")]
	public ResourceData Resource;

	[Tooltip("The quantity of the resource.")]
	public int Quantity = 1;

	public RecipeComponent(ResourceData resource, int quantity)
	{
		Resource = resource;
		Quantity = quantity;
	}

	public override string ToString()
	{
		return Quantity.ToString() + " " + Resource.name;
	}
}


//RecipeComponentPropertyDrawer.cs

using UnityEditor;

[CustomPropertyDrawer(typeof(RecipeComponent))]
public class RecipeComponentPropertyDrawer : ItemQuantityPropertyDrawer
{
	public override string ItemPropName
	{
		get { return "Resource"; }
	}

	public override string QuantityPropName
	{
		get { return "Quantity"; }
	}
}

Separate your code files into 'Game' and 'SDK' folders

Put any code files that are specific to this game in the 'Game' folder. Put any code files that might be useful on your future games in the 'SDK' folder. The idea here is to create a folder that you can literally copy and paste into your next project (or you can use a git submodule if you jump back and forth between a lot of projects).

You need to follow one rule to make this work: code in the 'SDK' folder can never reference code in the 'Game' folder. If this happens, either (1) rework your SDK code so the Game code can insert its own behavior - for example, provide an event it can subscribe to, or virtual methods it can override - or (2) put that code in the Game folder.

My SDK folder contains things like:

Static classes full of utility functions (MathUtility, ListUtility, etc).
The abstract property drawer above (in an Editor subfolder).
My generic input context system.
Generic helper components, like PositionAtMouse, MirrorColor, GameObjectPool...
etc.

If do this, you will write better, reusable code and save yourself time debugging this project and implementing these functions on the next.

Use a GlobalData ScriptableObject

ScriptableObjects are a great tool for organizing data. I like creating a scriptable object for each item, ability, and other such thing in my game to hold all the data associated with it. On Periodic Deliveries, I also created a monolithic 'GlobalData' object. This object holds all those global configuration options that usually end up throughout the project on various manager components and code constants. Putting them in one place meant I never had to spend time tracking down where so particular value was. The scriptable object also diffs much better in source control than a component in a scene, in case you need to look back through the history.

The GlobalData object can be held on a global singleton component somewhere, or maybe loaded with the new Addressable Asset system (I haven't played with it yet).

I hope some of these tips can make your development a little faster and more fun. If you're into space, simulation, or management games, don't forget to check out Periodic Deliveries on Steam!

Periodic Deliveries - Steam Release!

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 07 Dec 2019 16:36:17 -0600

Way back in Ludum Dare 30 Justin Britch and I made a game called Space Transport Tycoon (which you can still play in your browser for free. Four years later, we still remember it fondly as the the game we spent the most time actually playing after making it. This year, we finally resurrected it as Periodic Deliveries and we're publishing it on December 17th on Steam!

Check out this before-and-after:

We've obviously upgraded the visual quality, thanks to our real artist, John Lewis. The game still features the same core mechanic - configuring trade routes between planets to move certain goods from where they're produced to where they're needed - but we changed several peripheral mechanics. In the game jam, I wanted to create a game with multiple views shown simultaneously. That's how we got the planetary view at the bottom-right, where you could relocate factories to tiles that had more optimal conditions, based on the type of factory. This ended up being one of those features that had a lot of cool stuff in the implementation but didn't work in practice - it was just a quick chore to do once on each new planet. We removed it to focus on the main view.

One small change had a big impact: we prohibited trade routes from crossing each other. In Space Transport Tycoon, you'd often build a crisscrossing web of routes that wasn't terribly satisfying. The new restriction requires the player to use certain planets as hubs and create arterial intermediate routes, which we think is an important and cool part of the shipping fantasy.

The UI also got a big rework. The old UI was "planet-centric" - that is, you selected a trade route and were presented with a list of every planet on that route, with controls to configure the behavior at each planet. This allows the player to picture everything that happens at a particular planet little more easily, but it requires extra mental steps to think about what happens to a particular good across the entire route - the later being much more useful to the player than the former. The list can also get arbitrarily long, which is kind of a UI nightmare. Periodic Deliveries now uses a goods-centric UI, where the player sees a list of goods that are involved with the route, and configures which planets import or export that good.

That's just a few of the larger changes we made for Periodic Deliveries. If it sounds like something you'd like, try out Space Transport Tycoon right now and wishlist Periodic Deliveries below!

This post has been updated: the explanation of planet-centric vs. goods-centric UI was backwards.

Sizing elements to fit their contents in Unity UI

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 10 Apr 2019 11:19:09 -0500

You have a UI widget that contains a number of different elements (text, images, etc). These are all children of a background element, which you want to automatically resize to encompass all of these children.

You read a bunch of forum threads and the documentation and it just won't work. Me too. I figured it out, though, so I'm documenting it here. This was written with reference to Unity 2018.3.3.

To demonstrate, I'll be creating a tooltip. I'm starting with a naive implementation - a few different widgets that are children of a VerticalLayoutGroup.

The first important concept to understand is the idea of "preferred" size. Preferred size is an internal value that some UI components have (specifically, ones that implement the ILayoutElement interface). It doesn't have anything to do with any of the values of the RectTransform on that element. Some examples of components that have a preferred size:

Image - The preferred size is the original size of the sprite being used.
Text - The preferred size is the size of the actual visible text.
Layout Groups - The preferred size is the size of the bounds encompassing all of the group's children.
Layout Element - Allows you manually set the preferred size for an object.

By default, Layout Groups look at the RectTransform size of their children when deciding how to position them, not the preferred size¹. Remember that for Text components, the visual size of the rendered text is the preferred size, not the RectTransform size. So in order to include Text in a Layout Group and have it respond to the actual rendered text, we need to set the text's RectTransform size to match its preferred size.

There is a built-in component for this called ContentSizeFitter. When attached to a GameObject with a UI component on it, it can set the RectTransform size of that object to match the preferred size.

I'll attached ContentSizeFitters to each of the Text objects and set the Vertical Fit to "Preferred Size". You may have to disable and re-enable the VerticalLayoutGroup to get it to refresh. You'll also see a warning message on the ContentSizeFitter component about the parent layout group, which you can ignore for now (but see footnote 1).

This is getting closer, but the background (an Image component on the Tooltip object) isn't resizing yet. Remember that the preferred size of the VerticalLayoutGroup is the size of the bounds encompassing all its children. So let's just add a ContentSizeFitter to the VerticalLayoutGroup object and set both fits to "Preferred Size".

And that's pretty much it. You can use the Padding and Spacing properties on the Layout Group to clean it up.

¹ Layout Groups have two checkboxes for "Child Controls Size", one for the Width and one for the Height. Checking these boxes causes the Layout Group to automatically perform the function of the ContentSizeFitter - changing the RectTransforms of the children to match their preferred size. This allows you achieve the same result without ContentSizeFitters, and it is apparently how Unity now intends it to be done; however, it affects ALL the children of the layout group. That includes the divider in this case, which we didn't want to resize. We could have fixed this by adding a LayoutElement component to the divider and setting its preferred height to 1.

One more thing

What if I wanted to introduce a second part of the background - a border? Ordinarily, I would make the border a child of the background and set the RectTransform Anchors to stretch both dimensions. But that won't work in this case because the background can no longer find the content items (Layout Groups only operate on their immediate children), so it won't grow to match them.

What we really want in this case is to pass the size up from a Layout Group on the border. I move the Layout Group and ContentSizeFitter from the background to the border. Now the border is sizing correctly, but I need to get the background to match it as well.

Remember that Layout Groups set their own preferred size to the size of the bounds encompassing all of the group's children. So we can achieve this by adding a Horizontal or Vertical Layout Group to the background (they will produce the same result with only one child), which sets the preferred size, and then adding a ContentSizeFitter to the background, resizing the RectTransform to match.

Unity UI Gradient Shader

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 14 Feb 2019 15:01:23 -0600

EDIT: An updated version of this shader that supports Sliced images is available here.

I created a variant of Unity's default UI shader; instead of using a solid tint color across the entire element, it uses a four-color gradient. The source is MIT-licensed and available on GitHub.

Unfair (Board Game) Card Blanks

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 11 Jun 2018 14:34:36 -0500

In a departure from my usual medium of digital games, I've created blank card templates for every type of card in the game Unfair. These are based on the print-and-play version of the game, so they have some compression artifacts and Print-And-Play watermarks, but they do nicely for personal use. They're in Photoshop PSD format. Click this image to download.

UCI Game Developers Week Lecture: Tools in Unity

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 27 May 2018 00:49:50 -0500

I spoke yesterday at the UC Irvine Video Game Development Club's Game Developers Week. I discussed the four major methods for creating tools in Unity (property drawers, custom inspectors, editor windows, and gizmos) to help develop and debug Unity games, and showed some specific examples of each from Pillars of Eternity and Pillars of Eternity II: Deadfire. I also shared about my tool for browsing references to and from any asset in a Unity project, which is now available on Github.

Click this image to view the slides:

ASCII Art Generator

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 26 Mar 2018 01:27:06 -0500

A few years ago, I wrote a program that could produce ASCII art from raster input images. I was going to use it to generate paperdoll images for the equipment screen in an ASCII roguelike game. It worked great, but it was written using XNA and the images to convert had to be set at compile-time. Ick!

Now, I've finished converting the program to Javascript/HTML5, and made a number of other improvements. You can try it right here!

http://brianmacintosh.com/asciiart/

You can find a number of ASCII art generators on the internet, but they usually operate simply by selecting characters with more or less "ink" based on the brightness of each character-sized cell in the image. This method requires pretty large output sizes for the image to be recognizable. My generator uses edge detection to find characters that actually follow the lines of the input image, which holds up a lot better at smaller sizes. The downside is that noisier images (such as photographs) can produce noisy output that requires a lot of cleanup, though there are some steps that try to mitigate this.

The source code is under the GPL (3.0), and images produced with the page are free to use. You can visualize what each step looks like by adjusting the Debug Stage in the Advanced settings, and there are a number of sliders to play with the tweak the results. Here is an overview of the steps in the algorithm.

Greyscale the input image.
Gaussian blur the image to reduce noise.
Use Sobel edge detection to produce a greyscale image representing the edges present.
Threshold the edge-detected image, leaving us with a black image with white lines.
(Optional) Dilate the image, thickening the edges.
(Optional) Erode the image, reducing the edges. When used in combination with equivalent dilation, this can help reduce noise.
Blur the line image. This makes it easier for us to match up characters in the next step when the best match doesn't precisely line up with the grid.
Split the image into a letter-sized grid. For each grid cell, overlay ("convolute" is the technical term) each ASCII character over the content. Whichever character best matches the content of that cell is the one we'll use. We also try the characters at small offsets to try to catch, say, a vertical line that doesn't land quite in the middle of a cell.

A Different Approach to Pip-Based Bars

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 23 Nov 2017 03:35:44 -0600

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:

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:

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

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:

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.

Necromasser Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 25 Mar 2017 15:50:02 -0500

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!

Procedural Potion Icon Generator

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 08 Mar 2017 02:35:57 -0600

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

Make potions here

Persistent data in the Alexa Skills nodejs SDK

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 05 Feb 2017 00:59:07 -0600

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.

Contact Listeners in box2d.js

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 20 Apr 2015 17:49:56 -0500

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.

Ludum Dare 32 Brainstorming

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 18 Apr 2015 12:31:16 -0500

Brainstorming thought process for Ludum Dare 32: An Unconventional Weapon.

I like airships.
Unconventional airship warfare?
Porcupines.
What's more fun than airships slinging porcupines at each other?
Porcupines flying airships, slinging themselves at each other!

Camera Obscura Indie Royale

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 25 Mar 2015 17:28:07 -0500

I'm excited to have Camera Obscura featured in this week's Indie Royale game bundle! Pay what you want for Camera Obscura and 5 other games. No reason not to pick it up now!

The Venetian Bundle

Camera Obscura Steam Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 10 Feb 2015 03:05:29 -0600

It's happening. Three years after its inception, Camera Obscura has made it through Steam Greenlight. We've been hard at work through January getting everything ready for release, and it's coming on February 19th. I'm excited to finally get the game out to players so they can enjoy it!

For more information, visit cameraobscuragame.com.

Magic Mobile Website Compatibility

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 31 Jan 2015 21:39:45 -0600

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:

<style>img{max-width:100%;}</style>

Which simply instructs every img element on the page to be no wider 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.

Outpost: New World (Ludum Dare 31)

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 29 Dec 2014 00:28:43 -0600

Just a few weeks ago, Justin and I participated in the 31st Ludum Dare. The theme: Entire Game On One Screen.

We decided ahead of time that we wanted to make a game that was more action-packed and also more polished than our usual fare. I'm not sure we totally succeeded in overcoming our propensity for making fairly complicated simulation games, but we did manage to make our most polished jam game yet. Play it here!

Outpost: New World

Our past experience with game jams lead us to decide that we wanted to be done with the core game by early afternoon of the second day (sooner than halfway through the jam). We would then use the second half of the jam entirely for polish. While we fell behind on that goal, finished the core game around 6 in the evening of the second day, that still left us the entirety of Sunday for polish. It worked out very well - I was able to put together a very dramatic opening cinematic, a generate a full range of sfxr-generated sound effects, and record some moody cello music (three elements that we usually don't have time for in jams).

While I'm not a huge fan of how the final gameplay turned out, others seem to be enjoying it much more than any of our previous attempts. We'll see what the results show in about 21 hours.

Ludum Dare #30 Results

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 17 Sep 2014 11:48:54 -0500

Results for the past weeks' Ludum Dare judging are in! While we knew we had made a game that was ill-suited to the judging style of the Ludum Dare, in which people have to play and judge a lot of games in a short time period, there were definitely some who really enjoyed the complexity and took time to learn the game.

	Coolness	84%
#99	Theme(Jam)	3.76
#345	Innovation(Jam)	3.11
#487	Humor(Jam)	2.13
#487	Overall(Jam)	3.06
#532	Graphics(Jam)	2.98
#597	Fun(Jam)	2.64
#618	Mood(Jam)	2.61
#629	Audio(Jam)	1.83

I played some other really cool games while I was judging. Here are a few that I stumbled across:

Tough Love Machine - A remarkable innovation on the classic sliding-block puzzle.
This little piggy - It has bacon in it.
Bidimensional Landscaping - A quick game with a unique new mechanic.
Fluid Perspectives - A very nice little platformer
Ferryman - It's a humorous and witty take on the theme.
Toward Toward Heaven - Shares our plight of being pretty complicated, but I kept coming back for more of it. A unique take on "multiplayer" games.

Space Transport Tycoon

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 25 Aug 2014 11:09:37 -0500

And the game is done as of last night. I think this one went well, considering Justin didn't stop playing it for 4 hours after we finished.

It's a space economy simulation game. You the player must build a network of trading routes to move materials to factories and consumers.

Play in your browser!

Space Transport Tycoon

Ludum Dare 30 Go Time

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 23 Aug 2014 11:13:05 -0500

Just starting the first real day of coding for the 30th Ludum Dare. I started off this jam thinking of making some kind of simulation game - something where you, in a relatively low-pressure environment, could build up a system or a network and watch it do its work, like SimCity.

Justin and I had a short brainstorming session when the theme - Connected Worlds - was announced. They say to never go with your first idea - however, after considering two-screen tower-defense games, games where dinosaurs are attacking the modern world, games with constellations (I really liked that one and I hope some other people do it), and meeting Kevin Bacon, we eventually went with just that. This will be a game where you build up an interstellar shipping empire, moving goods between planets.

I also wanted to try to make use of multiple windows or views, and that goes well with theme. We're pretty sure we know what we are going to do with them. Early screenshot:

Some Pixel Art

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 03 Aug 2014 20:31:27 -0500

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

Ludum Dare #29 Results

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 19 May 2014 23:37:58 -0500

The results are in from Ludum Dare #29. Fun being probably the most important category to me, I am quite happy with my rankings. I'm definitely improving over my scores from the last two jams, and I was happier with the game as well. The Dare had a record-breaking 2497 submissions this year.

	Coolness	82%
#64	Theme(Jam)	3.84
#140	Fun(Jam)	3.42
#211	Mood(Jam)	3.43
#240	Innovation(Jam)	3.30
#249	Overall(Jam)	3.39
#316	Audio(Jam)	3.18
#318	Humor(Jam)	2.70
#485	Graphics(Jam)	3.07

During the judging period, I played 60-something games. You can find lots of "best-of" lists around - here are the best games I happened to play.

Infection - A pretty tower defense game in Unity.
Kinetectonic - A very fun-to-figure-out puzzle-type game.
Ben Eath the Surf Ace - A surfing game that's totally rad, dude.
Shark, Shark, Shark - Shark, shark, shark, I'm a shark. It has claymation!
A Glorious Escape for a Lich King - A really solid all-around tower defense game.
Jumpland Underground - This game is art.
Damned Scouts - A fun puzzle game about camping safety.

.gitignore: permit only certain paths with negation

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 15 May 2014 19:13:04 -0500

Today I was trying to create a .gitignore file for a project that has to live in the same directory as a number of different folders. I wanted the git repo to only include folders that start with the string heroscape, while excluding any other folder.

The gitignore man pages point out that you can negate a pattern by putting a ! in front of it. I didn't notice at first that this does not ignore anything that does not match the pattern. Instead, it re-includes any previously ignored paths that match the negated pattern.

So to achieve what I wanted, I had to do the following, first ignoring all folders, then re-including folders that begin with "heroscape".

*/ !heroscape*/

Dawn: Infinite Runner Game

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 11 May 2014 03:17:31 -0500

Between the Ludum Dare, school, and everything else, I've been turning out a lot of small projects this month. I recently participated in a competition on The Game Creators. The competition, inspired by Flappy Bird, presented one goal: make the most addictive infinite game possible.

My entry, titled Dawn, also draws inspiration from the classic Canabalt. It's a sidescrolling runner in which you play a man who must jump, smash, and fly his way through a scrolling obstacle course as the days pass by.

This competition was focused on addictive potential, so I implemented a few different ideas in an attempt to grab the attention of players of the game:

Online Highscores: they give the player something to shoot for. He can see what other people have done, know that it's possible, and attempt to prove himself better than them.
Day/Night Cycles: My idea here was to give the player a concrete sense of progress - more visceral goals to shoot for than the elusive high score.
Feel: Polish. If the game simply feels good to play, I reasoned, people will want to play it more! Key elements of this in Dawn include particles when smashing through walls and a good set of character animations that makes you feel awesome when you crash through those girders. At the suggestion of Justin Britch, I took a minute to implement a simple animation at the game end: quickly ticking up the user's score from 0, rather than just displaying it. This gives the score a sense of weight and grants the player extra satisfaction at his achievement.

It remains to be seen how effective these strategies were. Clearly Flappy Bird didn't need many of these things to become what it did!

Ludum Dare #29 Complete

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 11 May 2014 02:43:50 -0500

A few weeks ago, I participated in the 29th Ludum Dare. It has been a while, but not many posts, since I last participated in the Dare. The theme for this one was "Beneath the Surface".

I worked with Justin Britch on this one. We met just after the theme was announced to brainstorm. I really liked this theme - it evokes mystery and exploration, provides an easy setting (underground or underwater) to start with, and could simultaneously be tied into gameplay elements. While we thought it would have been a lot of fun to make "Ben Eath, the Surf Ace", we ultimately decided that we really wanted to go after the mystery, the thrill of exploration, fear of the unknown, and such themes. We also knew that we wanted to attempt to introduce some sort of narrative into the world.

The beginnings of the conversation system.

The design was ambitiously scoped for a jam, and I'm happy I was able to turn out so many features.

More conversation.

The Good: Dedicating time during the development process for polish worked well for the game. When polish gets left as a task for the end of the jam, there's often no time to actually do it. I didn't leave a feature until it was in a state it could stay in.

I also didn't run into too many momentum-killer problems. I've worked on several smaller projects using HTML5 and ThreeJS over the past few months, so I knew some of its quirks and was able to work continuously without getting stuck on strange bugs, even though the codebase for Thunder Fish pushed way past the size of my previous HTML games. Familiarity is key for jams, and it definitely pays off in the ability to continue grinding out features.

Learned: Yet again, I completely failed to allocate time for audio. Fortunately, I was already in the Jam category for this one, so I pulled some free music from NGXmusical in the last hour. Sound effects could have improved the feel even further, though.

You can play The Legend of the Thunder Fish on the web!

Also some of the other Dare games, here: Ludum Dare 29.

What is Flatricide Pulgamitude Anyway?

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 01 Mar 2014 18:42:19 -0600

I recently released a small game called Flatricide Pulgamitude. This game is an experiment for me in pseudo-multiplayer game development. By that, I mean "I really like games you can play with other people, but I don't want to have to manage a real-time game server". Therefore, I set out to make a game that you could play with others online with only some PHP scripts and a MySQL database.

The result of that is a game in which you wander a strange abstract world built by people who have come before you. You can't see other people in real-time, but you can explore their work and build your own for others to find.

So why the strange name? The other impetus behind this project is a class competition to get a page to the #1 spot in Google Search for the term "Flatricide Pulgamitude". To that end, I'd appreciate it if you could share a link on your own site!

You want to check it out? Just click on this pulgamitude (whatever that is):

Keeping cmd windows open with /K

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 29 Jan 2014 13:28:34 -0600

I like using .BAT files to run common tasks like compiling Java code or starting my NodeJS server. It's very convenient to just execute a .BAT where you've already written out all the proper parameters rather than typing out an entire call every time you need it. This does cause a problem, though - if any of the programs that execute from the .BAT returns an error code, the command window will immediately close. This makes it impossible to debug those programs.

I tried adding the pause command at the end of each file, but to no avail - the command window exits immediately when a program returns an error and doesn't execute the rest of the file (which is responsible of it, admittedly).

The solution was to use a parameter to the cmd program itself:

cmd /K bat/mybat.bat

The /K parameter keeps the window open even if the .BAT stops executing. I simply copied all my .BATs to a subdirectory and created wrapper bats using this line.

Ludum Dare #27 Complete

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 02 Sep 2013 22:26:06 -0500

Last weekend, I participated in the 27th Ludum Dare. For anyone who doesn't know, the Ludum Dare is a competition held a few times a year in which participants attempt to make a game in 48 hours. Games made for this Ludum Dare had to follow the theme "10 Seconds".

When I first heard the theme, I was a bit put off. I thought it was too shallow, too easy to just tack onto an arcade clone. Fortunately, many brilliant people proved me wrong. However, I opted to take the theme a little more laterally, interpretting "seconds" as a measure of distance based on global lat/lon coordinates. I thought, "what if there were only 10 square seconds of the earth left?" The earth would just be a really small section of the surface (about 300 ft on each edge) and a huge slice of the core dropping off into nothingness.

That sounded like a great setting for a survival-horror game, something I hadn't tried before. The design I ended up attempting to implement was very ambitious. Overall, I think this was a good plan, even though I certainly didn't get to everything I wanted to. I was considering and developing a lot of extra content for the game, rather than just taking the first few things I thought of and ending design because of scope. Of course, over-scoping is still a terrible thing, but by prioritizing things that needed to get done, I was able to still have a playable game after 48 hours even while not reaching all my goals.

I did neglect the gameplay aspect of the game a bit during this jam. Had I been able to implement some form of combat and developed the building mechanics more, the game would have become much more viable from a gameplay perspective. So perhaps the scope did kill me there. I ended up getting to explore ideas for creating ambiances and environments, though, and I think on that front it went fairly well.

You can play my entry here: The 91st Parallel.

Forays in Web Crawling

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 16 Apr 2013 02:02:21 -0500

I've always been really interested in the idea of gathering data from the internet. It probably stems from my love of organizing, classifying, and recording stuff. I finally took an opportunity to exercise this interest this week.

On the forums for the (amazing) game Dwarf Fortress, there is a thread dedicated to illustrating "forgotten beasts" from the game. Forgotten beasts are terrifying monsters that are randomly generated by the game and lurk in the depths of the earth. Because forgotten beasts are rarely alike, the thread has seen a great variety of works from some outstanding artists. I wanted to collect these illustrations and organize them into an archive where people could browse them by artist or by the beast.

To collect what ended up being over 650 images from a 150-page forum thread, I created a web robot in C#. This part of the task provided some interesting challenges. The robot had to collect the URLs of any images that were posted in the thread and their authors, as well as the actual text descriptions of the beasts being illustrated, which were sometime in text form or in the form of screenshots from the game. Fortunately, the descriptions follow a certain identifiable formula that made it possible to pick them out with good success from all the other text in the thread. To actually associated the beast pictures with the proper descriptions and to find and transcribe the descriptions that were embedded in screenshots, I turned to a sort of "crowdsourcing" model - I set up a simple PHP page to show images to viewers and ask them to classify them. This was an easy way to finish these tasks that would have been impossible for an automated program to do (though I contemplated incorporating some kind of OCR to look for text descriptions in the images and transcribe them).

To check out some of the great art this thread has produced, visit the archive page: https://www.brianmacintosh.com/beasts/

New Blog Feature: Tags

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 23 Mar 2013 19:04:17 -0500

I've updated the blog again with another new feature - tags. Each post is now tagged with a number of strings based on what it's about. To see more posts about the same subject, just click on one of the tags in the top line.

Computers in computers - Camera Obscura Adder

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 17 Mar 2013 01:00:53 -0500

It's always fun to see people building computer-like circuits in games like Minecraft and Dwarf Fortress. While it's outlandishly impractical to build computers in computers, it's just so much fun and so educational. Well, today I figured out how to do it in the Camera Obscura engine using moving platforms and I was irrationally excited about it, so I built a four-bit adder circuit. It adds two four-bit numbers together and show the results. Check it out:

You can download the level here.

Boring details on how this works: there are several very small sets of logic gates, the basic building blocks of electronic chips, that can be provably used to create every other possible logic gate (trivia: NAND gates alone are sufficient, as are NOR gates). Camera Obscura's mechanics are capable of creating two gates: OR, by simply linking multiple sources to the same moving platform, and NOT (at least as far as I've discovered). Fortunately these two gates together are sufficient. Information can propagate through the system because moving platforms can press buttons that trigger other platforms...and so forth.

This possibility also provides some pseudo-scripting functionality to game levels. Imagine a passcode-protected vault that only opens when you enter the right number, or even a game of Mastermind within the level.

Camera Obscura Demo Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 28 Feb 2013 04:05:47 -0600

This week marks the first public release of a playable demo for Camera Obscura! The released demo contains 20 levels out of the 100 total in the full game. We have also included the full level editor, so you can make and share custom levels without limit.

We are very excited to be at this stage where we can finally begin to get solid feedback from people based on how the game actually plays. Please download it and let us know what you think, and remember to support us on Greenlight!

Download
Demo Installer (Recommended)
Demo ZIP

The process of releasing a demo was a surprisingly lengthy one. I always thought I would just compile a release build, stick a readme file in it, and send it out to the internet. As it turned out, however, there were numerous aspects of the game that had to be examined and tweaked to make sure publication went (and continues to go) smoothly. In addition to the normal, everyday tasks of polishing features and tackling bugs, I had to consider what parts of the user's saves needed to be kept for future versions of the game (like their options and achievements) and which parts would need to be thrown out later, and build in a mechanism for allowing that. I also had to build an installer to ensure the users would have all the right dependencies (runtime dependencies can suck). And, of course, we had to test the heck out of every other aspect of the game, as well. The thought of someone putting aside the game because it crashed on the menu screen is not a nice one. So there's my semi-educational post-mortem thing for publishing a demo.

XNA Bitmap Font Library Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 31 Jan 2013 19:41:57 -0600

I've just released some code I've had for a while. This library allows you to use bitmap font images to draw fancy and stylish text to the screen in an XNA project. It was used in Music Island to strings using bamboo-styled text.

More information and downloads are available on the code page.

Super Pirate Box Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 26 Jan 2013 15:33:43 -0600

I finished up polishing the menus and high scores for Super Pirate Box. The completed game is now available on the project page!

Features:

Frantic pirate-shoving action
Online high-score tables
Silliness
Local statistics and personal high-score tracking
Electromagnets as cheap plot devices

Hope you enjoy it!

Camera Obscura on Steam Greenlight

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 22 Jan 2013 14:41:28 -0600

Camera Obscura has been submitted to Steam Greenlight as of this Sunday! We've very excited to have a shot at publishing the game as we approach 2 years of development. Visit Greenlight here and vote for us:

Camera Obscura \ Steam Greenlight

We've also released a portion of the soundtrack on Youtube for your enjoyment:

Camera Obscura Soundtrack

Super Pirate Box: 48 hours postmortem

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 20 Jan 2013 04:12:36 -0600

Last weekend, I participated in a 48-hour game jam with UCI's Video Game Development Club. I had a lot of fun pulling a couple of 14-hour workdays with my fellow game developers. Together, we turned out four games in the weekend, spanning platforms including XNA, Unity, and SDL.

I decided to use my weekend to learn more about using SDL with C++ to develop a 2D game. I spent some time in the preceding weeks writing some libraries for spriting and controls to simplify the process, but of course, there were still a few issues during the weekend. For one thing, I hadn't realized that SDL doesn't load PNG images natively. I was able to implement the SDL_image library, but that set me back a bit.

Anyway, the game itself it an arcade-style top-down game. You play as a pirate who must repel legions of enemy pirates who try to board your ship. However, for some reason neither you nor any of the other pirates have weapons. So what do you do? You attempt to shove them overboard, of course. It's fast-paced action, easy to pick up, but difficult to master - and one slip-up means starting over from zero!

I hope to be able to wrap the game up within a week with some basic menus and online highscores.

Update: Get the game on the project page.

Side Project: Random Music Generation

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 10 Dec 2012 21:18:09 -0600

This week's random side project was inspired by my friend Bryan Ploof and my Music and Technology class. We've been discussing music generated by computers with little or no human influence, including attempts to map anything from fractals to sorting algorithms to musical notes. Michael Matthews gave a lecture on his research in creating music using cellular automata. Cellular automata are sets of simple rules that define how a grid of "cells" evolves over time. They provide very interesting possibilities in the generation of music because their rules often generate musically interesting patterns and progressions. Michael's approach was to use a one-dimensional automata to control the pitches and timbres of sound available to a player, who modulated the sound directly through motions picked up by a webcam.

My goal was to make a system that could act autonomously to create a unified tune with a strong melody. My approach was to create three seperate automata to control different aspects of the music. One controls the rhythm of the song by selecting the timing of each note (quarter, eighth, etc). The other two control the notes that are played: one selects a chord from a pre-defined set, and the other selects which notes from the chord are activated.

Here's a sample! This video uses a few chords selected from the Star Wars theme to generate a tune.

An executable and the full C++ source are available on my code page. Future plans for the project may include replacing the chord-selection mechanism with a Markov chain to make it more musically coherent, and implementing samples and ADSR so the notes can be things other than sine and square waves.

Camera Obscura IGF Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 02 Dec 2012 22:39:23 -0600

Here's a long overdue update on Camera Obscura. It's been quite a while since I've posted about it, but work has been continuing on. We submitted the game to the Independent Games Festival, for which the results are expected in January. The current plan is to beginning working on release at that point, hopefully with some more recognitions to our name!

There's tons of new stuff now, including over 50 levels, a vast array of background and tile art, and a number of new features for tracking statistics, best scores, and achievements. Oh, and a final level, complete with cutscenes and a "final boss" of sorts. This video should demonstrate some of the new shinies:

Windows Phone Code Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 26 Nov 2012 15:48:15 -0600

About a year back I wrote a couple of classes to aid rapid Windows Phone app development in my development group. I've decided to release them on my site and announce them in the hopes that anyone else might be able to make use of them.

This includes these three files: The static TMicrophone class and the static TAccelerometer class, which provide wrappers on the the existing microphone and accelerometer APIs that greatly simplify their use - most useful functionality is available through simple wrapper methods. The final file contains Sprite and SpriteSheet classes that provide simple, lightweight spritesheet loading and sprite creation, with variable-speed playback and circle-to-circle and box-to-box collision.

For more detailed information and downloads, visit this page: https://www.brianmacintosh.com/code/code.php?id=3

Primeval (Tiles) Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Fri, 09 Nov 2012 14:57:36 -0600

I just uploaded a small update to Primeval. It fixes a bug where the music did not loop, and improves the animations for transitioning from win and lose states.

New Game: Primeval

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 31 Oct 2012 18:49:41 -0500

I just posted a small game I've been working on lightly since the Ludum Dare 24. The game, Primeval (not to be confused with Primeval Labs), is the second of the two ideas I was considering for the Ludum Dare. It's a rather mind-bending tile-swapper combining mechanics of Conway's Game of Life and Rock-Paper-Scissors. My goal in creating this game was to learn Flash and ActionScript 3 while experimenting with this idea. I had opted to create the more traditional and straightforward Primeval Labs for the Dare because I wasn't sure how well these mechanics would balance or whether the game would even be viable. After a few iterations in Flash, fortunately, it is, and now you can play it right here!

Here's a picture:

Side-Project of the Week: Randomized Dungeons

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 03 Oct 2012 14:55:16 -0500

This week, my friends Chris and Kevin and I were hanging out late one night. This, of course, led to a number of crazy ideas being bounced around (this, of course, is how most software engineering gets started). I actually decided that one of these crazy ideas might be doable, cool, and useful: a program that procedurally generates tabletop-RPG-style dungeons: monsters, loot, and most importantly, interesting and complex maps. I'm also using the project as an opportunity to learn more about rendering custom controls in a native Windows Forms project.

This is what it looks like, about three days later:

It can certainly generate some very entertaining map layouts, what with the occasional hallway where the floor is lava.

48 Hours Later

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 27 Aug 2012 19:12:26 -0500

The game, entitled "Primeval Laboratories", is done as of 6:00 PM yesterday! I think it turned out well. I had a lot of fun making it and testing it, and seeing a genetic algorithm finally working is very satisfying.

I've always been decent at art for a programmer, and I guess I assumed that I'd be able to do music and sound as well. Well, not in 48 hours, at least. So I learned that I stink at that!

Check it out here. I'll probably be making a page for it on my site here as well.

Genetic Algorithms are Interesting

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 26 Aug 2012 02:49:59 -0500

The game is looking pretty cool, by the way, at least in my opinion. Maybe I've just overly fascinated with this genetic thing.

I'm not quite convinced that it's working correctly, though. One trial run I did thought it would be a good idea to breed out every single weapon gene except for a single (rather mediocre) lime-green laser beam. To make matters worse, the children kept wasting their mutations on stupid things like turning the laser hot pink. I'm bumping up the importance of dealing damage to try to tackle this. It's possible that we're just suffering from an extremely small sample size.

Particles

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 25 Aug 2012 19:26:12 -0500

They make everything better.

I think this will work

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 25 Aug 2012 16:24:10 -0500

I had a moment just now that greatly reassured me with this game's design. I just finished implementing the basic enemy logic - shooting, dying, and finally moving. The game, as I mentioned, is about randomly generated enemies that evolve with genetics (i.e. the ones that do well get to reproduce and make new enemies).

After several of the enemies bobbed around shooting me, all of a sudden one popped out of the spawner, dove to within 20 pixels of me, and starting circling and bobbing really fast. It proceeded to destroy my face.

Here are some pictures, but I think I need a video or demo to really show it off.

A big fat enemy

Enemies can have three types of weapons - lasers, bullets, and missiles

Ludum Dare #24 Is Fun

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 25 Aug 2012 02:08:57 -0500

As expected, I wishy-washied over my game ideas some more and finally settled back on the shootemup with evolving enemies. I've started writing code now, so what's done is done as far as that goes. The skeleton code for genome selection, crossover, and mutation is all in place, and I've working on fleshing out the actually movement and firing code for both the play and the bots - that's going pretty well.

The plan is for the game to spawn little evo-bots at a rapidfire pace to try to kill you. They'll be ranked based on how long they live and how much damage they do to you. After a certain number of spawns, the best ones will be picked and crossover and mutation will occur. Repeat. The "genes" that will get messed around with include stat boosts, weapons (and their individual stats), other gadgets like armor plates, and such.

Also, it's a bit late for my brain. In case you were wondering.

Ludum Dare #24 Game Jam

webmaster@brianmacintosh.com (Brian MacIntosh) — Fri, 24 Aug 2012 22:13:42 -0500

A few days ago I heard from a friend about a competition for crazy people. Its creators would have you, given nothing but 48 hours and a theme, make a complete game. Naturally, this sounded like a pretty worthy use of 48 hours to me, so this is what I am doing as of about an hour ago.

The required theme this weekend is "evolution". I was got pretty attached to the first idea that popped into my head, which was a shmup where the enemies come in waves, each with a variety of features like armor and shields and unique guns and stats like attack speed and power. Each successive wave would be born from the most successful enemies of the previous wave - the enemies gradually becoming more and more deadly. It took some doing, but I managed to convince myself to think through some other ideas. Here I am about a (rather emotionally trying) hour later, with a different, rather simpler idea that's going to look more like the puzzle game offspring of Rock-Paper-Scissors and Conway's Game of Life. It would take far too long to explain it now, and I'll probably change it all anyway, but that's where it stands. More as it happens!

http://www.ludumdare.com/compo/

Mage Cage - Thunderfish Entertainment

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 23 Jun 2012 12:36:14 -0500

Thunderfish Entertainment will be submitting another game to XBox Live Indie Games soon...

More information as we progress through the review process in the next few weeks.

Normal Mapping Code Released

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 22 Apr 2012 22:59:13 -0500

I was working on adding specular mapping to the normal mapping demo (a technique that imitates the "shininess" of a surface), but I ultimately decided to release the basic code now and perhaps create an updated library later. Enjoy :).

Download Here

Dynamically Lighting 2D Scenes with Normal Maps

webmaster@brianmacintosh.com (Brian MacIntosh) — Fri, 13 Apr 2012 12:45:15 -0500

My random inspiration of this week occurred when one of my professors, Dan Frost, mentioned basic lighting techniques in lecture. It turns out that for any surface, the final color of that surface with a light on it can be calculated quite simply by multiplying the surface's color by the color of the light times the dot product of the surface normal and the normalized vector from the light to the surface. I thought to myself, "I could totally do that." Any about an hour later, I had this demo up and running:

Normal mapping has been traditionally used in 3D games on surface textures for 3D models. In this context, its use can easily make an extremely low-poly object appear much more detailed at a low processing cost by rendering textures with lighting such that they appear to "pop out". In this demo, I have instead used it to fake a 3D effect on a completely flat 2D plane.

The process is fairly straightforward. First, the standard scene is rendered to a render target cleared black, with nothing special done. Then, the scene is rendered a second time to a second render target, but this time the normal maps for each image, if they have one, are drawn instead of the standard image. Normal maps encode information about the surface normal, or the direction the surface faces, of each pixel in an image. In most implementations, the X, Y, and Z components of the normal vector are encoded as the R, G, and B components of the color of a pixel on an image. This can be seen toward the end of the above video. This second render target is cleared RGB(128, 128, 255) so that images that do not have normal maps can be rendered as flat planes. Finally, both of these renders are passed to a shader that calculates the final color of each pixel in the first image using information about the locations and colors of all the lights in the scene, and the pixel's normal from the second image.

I plan to post the code from this demo soon, after I get my work on ambient light, directional light, and multiple point lights in there, so look out for it!

Making Music Games (a programmer's postmortem)

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 20 Mar 2012 00:39:09 -0500

Being a rhythm game, Music Island presented a number of unique and fun challeges from a programming perspective. The great difficulty in programming rhythm-based games is in keeping gameplay synchronized with the game's music. A fully-featured triple-A engine like BASS might be able to analyze the music in real-time and use it to guide gameplay. However, for our one-programmer team, analyzing the stream in real-time was not really an option. We would have to find some way to overlay music onto the game and force the game to keep pace with it.

The concept was fairly simple. We would use MP3 music. With the length of the song, the number of measures, and the time signature, I can calculate the time in milliseconds between each beat - or any subdivision of the beat. When the song is running, the program keeps track of which beat it is on simply by counting up with a Stopwatch. When the time exceeds the amount of time per beat, we go to the next one (carrying over the leftover time).

To have the game actually use this information, I determine what kind of beat the song was currently on (quarters, eighths, thirty-seconds, etc) and the distance in thirty-second notes from the nearest quarter note. If that value is within a threshold, I accept input and generate a spell.

I found that MP3 files were not actually a sufficient solution, for our resources at least (the XNA engine). Despite our best efforts to get accurate timings, I could not make the game stay in sync with the music. Within 5 or 10 seconds, they would be on off-beats, and XNA offered me no way to control how the MP3 was being played to attempt to correct this. I concluded that XNA's MediaPlayer class, which was playing the MP3s, was probably the issue, so our solution was to split the songs up into segments of WAVs. In addition, our songs were designed and composed such that they could be split up into layers by instrument. So we ended up with a bunch of two-measure wave files of single-instrument lines. I wrote an XML format so our composer could stack and sequence these segments however he liked. This helped cut down on the otherwise-huge filesize wav files would have caused by re-using tunes multiple times in a song.

Now with these segmented WAVs, we had far more control over the speed the music was played at, and we were able to synchronize the music periodically. This was ultimately sufficient to keep the game as a whole completely in sync. It was a feature we were still tweaking, though, even after the game's first submission!

Music Island RELEASE

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 19 Mar 2012 15:28:05 -0500

That's right, it's OUT! Music Island is finally through the XBox Live Indie Games review process, and was released just minutes ago on the same system.

I'm very excited to finally have been behind a truly published game. We're giving out the trial version of the game for free on the PC, and you can get it here as an installer that will take care of everything, or here as an executable if you already have the XNA and .NET frameworks. And, of course, you should buy it on XBox Live Indie Games!

Music Island Release Date

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 14 Mar 2012 13:03:19 -0500

Music Island has finally been approved by Xbox Live Indie Games, and the release date is set for March 19th! Finally, Thunderfish's first game will be out for purchase. I think all the work we've put in since June of last year has paid off, and we have a fine game to show for it. Pick it up if you can, especially if you're a fan of rhythm- and beat-oriented games!

RPG Engine Jam

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 19 Feb 2012 17:08:35 -0600

Yesterday I got roped into an awesome programming jam session with fellow game programmers Stephen Herlihy, Alex Naraghi, and Brenden Booth, aided and abetted by production Justin Britch and Bryan Ploof. Our goal: create an engine for a top-down role-playing game in the style of Diablo and Torchlight. Oh yeah, and users have to be able to build and play their own games in it with zero programming and scripting. Oh yeah, and we only had 12 hours.

It doesn't look like much (I'm a programmer, Jim, not an artist), but this demo features enemies, melee combat, player death, an attack spell, and jumping. What's more, it is paired with a well-featured editor, and both are built on an extremely flexible component system that defines functionality for generic "game objects" by assigning them components like Combatable, Impassable, and Mobile. Users can add generic objects to the game, alter their appearance, and change their behaviors simply by adding and removing components. You'll be hearing more about this one in the future.

Music Island Back In Review...

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 05 Feb 2012 17:46:06 -0600

The XBLIG review process has been long, but Music Island is in review for hopefully the final week or two before its release. Despite the lack of support for Live leaderboards for indie games, Music Island features a leaderboard system through the use of a distributed storage technique that should allow highscores to transfer through the system, giving players the chance to compare themselves to others in the game.

One reviewer: "My four year old couldn't get past the brown mask. She just kept saying 'the guy looks too weird and creepy'. I thought the art was cute, so take those comments with a grain of salt!"

Music Island Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 12 Jan 2012 02:22:20 -0600

Our first XBox Live Indie game has been submitted to peer review this week! This game was begun in June of last year and finished in early December. The remainder of December was spent shooting bugs, which were quite prevalent!

Music Island is a rhythm-based arcade-style game with generative music. In it, you must defend an island from streams of invading sea creatures by casting the appropriate spell at them on the song's beat. This action generates musical notes that build on the song's background rhythm. The game features a 10-level Story or tutorial mode, and the highscore-based Infinite mode.

This project was a good experience in working with a small team to make a clear, organized game. The game was produced by Justin Britch, with music and sound by Bryan Ploof and art and design by Jacob Anderson. The programming was done by myself. I will post when the game is approved and available on the XBox Live Indie system.

thunderfishentertainment.com

Camera Obscura Enemies

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 01 Jan 2012 13:06:19 -0600

Some new enemy art going into Camera Obscura. Aren't those walkers cute?

Orcs Must Die! Design Analysis

webmaster@brianmacintosh.com (Brian MacIntosh) — Fri, 23 Dec 2011 11:43:59 -0600

I haven't been moved to write one of these for a while, as you might have noticed. However, I started up a game called Orcs Must Die! today, and I am enjoying it pretty thoroughly. I had just finished hurling a column of hunched, waddling orcs into a pit full of acid with a wind spell and was watching my character drop some ridiculous dance moves when it occurred to me that the game was, on the whole, pretty silly. Orcs Must Die! uses silliness pretty effectively to create a fun and satisfying game, and that's what I want to examine here.

Watch this so you know what I'm talking about: https://www.youtube.com/watch?v=pioXot-rQ2U

Orcs Must Die! is a game about an apprentice whose master has just died defending a Rift from invading hordes of orcs. In a departure from tradition, said apprentice is not wracked with grief, but is instead rather excited to have acquired his master's tome of traps and spells ("Rest well, crazy old man!"). He takes up the task of defending various Rifts from the aforementioned hordes of orcs who would like nothing better than to fling themselves into them.

The reason Orcs Must Die! is so successful as a game is that it knows exactly what it wants to be. By that over-used saw, I mean that the developers had one guiding goal or theme for the game, it that theme is present in all parts of it. For Orcs Must Die!, the theme is "just have fun!" The short introduction cutscene sets the tone quite nicely, and the effect is maintained by the gameplay. At every point in the game, the design maintains in the player the sense of non-seriousness it begins with. Between the orc graphics, which are certainly cartoony in a Bastion sort of way, to the trap designs, which include such things as plates that fling orcs down the hall and the classic falling chandelier, there are certainly enough reminders of fun anywhere the player turns. Perhaps the best, though, is the character himself. The game is third person, and the main character has a definite identity seperate from the player. He keeps up a stream of snarky comments ("Here, mister orcky orcky") ("Gee, I hope no one gets hurt. Eh...not really.") that are the best anchor for the well-crafted atmosphere of "just have fun".

Of course, I don't believe that games that don't say "just have fun" are bad. Amnesia, for example, is themed after mystery and horror and of course suceeds in creating a game focused on just that. Where games fail is when they lose sight of the overarching themes they began with. The serious opening cutscene narrated by the character's master serves only to make the main character even more comical by contrast when it becomes clear that the game is not as dire as he makes out. A game similar to Orcs Must Die! that is, in my opinion, less successful in this field is Dungeon Defenders. It is strikingly similar, in fact, so it makes an excellent comparision. It has the potential and the setup to be a comical and fun experience like Orcs Must Die! - the opening describes how the four heroes that protect the land are lost, and it's up to their apprentices (miniature and caricaturized versions of the heroes themselves) to do so. Dungeon Defenders, however, loses sight of this theme in the midst of an RPG-style leveling and equipment system that is very reminiscent of games like Torchlight. It too uses a cartoony graphics style but there is little beyond that that follows up on any kind of overarching goal, and the themes of the game during gameplay don't extend much beyond "medieval style".

Now, there are a lot of Orcs Must Die! vs. Dungeon Defenders discussions on the internet, and they show that while these themes are important, people often buy games on criteria other than how fun the game was. On commenter said, "I'm waving on the side of Dungeon Defenders even tho I enjoyed the OMD demo a lot more," referring to the higher expected replayability offered by Dungeon Defenders by its RPG elements and multiplayer support. Themes and atmosphere are clearly not the only elements that make a successful game, but they factor in significantly.

Camera Obscura Trailer

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 30 Oct 2011 00:53:29 -0500

We've just recorded a new trailer of this nearly feature-complete version of Camera Obscura. It demonstrates some of our cool new features, like the crawler enemies (shown briefly) that can climb walls and walk on ceilings. One of my personal favorite features of the game so far. It also demonstrates the basic ideas of the gameplay more clearly, without all that mucking around testing collision ;).

Camera Obscura Status Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 10 Sep 2011 12:18:05 -0500

Camera Obscura is still trucking along. Summer is drawing to a close, and we hope to be done with the game's code by the time school begins. Most of the work that is left is with our level designers and our excellent artist, Dean Bottino. More gameplay videos and maybe some post-mortem-type stuff will be forthcoming.

Far Cry Design Review

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 30 Jul 2011 19:47:57 -0500

I played Far Cry (yes, the first one - on the PC, by the way) a few weeks ago, and thoroughly enjoyed it (well, a good 90% of it, anyway). While I'm pretty tolerant in general and don't often find a game that I don't like, there were a number of interesting design aspects of Far Cry that I think made it good. I wanted to look at a few of those, as they are things that others can easily emulate and that I think are better than their common alternatives.

I'm generally one of those people who says, "oh boy, it's another generic first-person shooter where you can kill completely unrealistic numbers of generic aliens/soldiers/terrorists while following the terrible linear plotline". And yes, Far Cry is this. But Far Cry does this in an extremely interesting and fun way that made forget about its genericness and really enjoy playing it. The main reason for this is the amazingly believable and interactive world Far Cry's designers have crafted. They have somehow created a world that is fun to interact with and explore, even though it's built around a cheesy rehash of the old Time Crisis mad scientist theme and populated by a really unlikely number of mercs.

How do they achieve this? What Far Cry has done is thrown out every cop-out design choice commonly used by designers of first and third-person games and replaced them with elements that serve the same purpose, but also feel like a natural part of the world. I guess the word to use here would be "immersion", though it seems overused in this field. I've picked out some of the great features of Far Cry's world below.

There are no hard world boundaries or "invisible walls", at least none that are reachable in the course of normal game play. The gating that keeps the player moving roughly along the route built by the game designers is incorporated realistically into the world. For example, steal a patrol boat and attempt to leave the island for the open sea? Almost every other game would place an invisible wall at some point out in the ocean, or perhaps kill the player with no good explanation as to his cause of death. We've come to accept these methods, and we don't (conciously) hate them, even though they are lame and immersion-breaking. But Far Cry does better. If you try to do this, the NPC narrator who keeps in contact with you via radio warns you that the mercenaries' radar systems will spot you on the open water. If you proceed, an attack helicopter flys to your location and guns you down. If you're looking the right way, you can even see the helicopter take off from the jungle and pursue you. This doesn't feel out-of-place or even unfair - I've neutralized attack helicopters before, and I feel like I have a chance against this one, but they're powerful enough that I don't feel cheated when it does get me. Most importantly, it doesn't break immersion like the repeated and highly unlikely excuse that there are "enemy mortars covering the area", the "return to the battlefield" warning, or the invisible wall.

The other common gating cop-out Far Cry revises is the "jungle path". Games that take place in a jungle, as Far Cry dominantly does, often try to keep the player on their neatly laid-out rails with walls of impassable shrubbery on either side of the path, or perhaps embankments that are just too steep to climb. These sorts of methods have the effect of slashing away huge portions of the game world in the player's mind. It doesn't feel like one world that they happen to be currently inhabiting a small jungle path within. It feels like a small path that exists only for them to run along it and complete the level. Far Cry, however, thrives on its small but (seemingly) unified world. It avoids this "jungle path" effect in two ways. One, it rarely tries to restrict the player closely to a path. Most games have to do this because they have laid out their enemies and their cover such that they expect the player to approach the encounter from a specific point, and if the player were to approach from a different direction entirely, it would break the difficulty of the encounter. Far Cry allows its level design to ignore these narrow restrictions because its enemy placement and AI are designed around this idea. The enemies mind their own business in camps and outposts until the player is spotted, at which time they are capable of taking cover, providing covering fire and attempting to flank and attack, and no matter where the player approaches from, they are capable of reacting dynamically to preserve the difficulty of the encounter. This allows Far Cry to achieve a very cool unity in its world, despite the fact that it is technically linear and divided up into a number of completely seperate "levels" as most games are.

I could go on, but I'm going to stop there for now.

Camera Obscura Early Gameplay Video

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 01 Jun 2011 02:11:20 -0500

As promised, the game now has all the significant animations implemented, so here's a video!

Camera Obscura Screenshots

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 29 May 2011 17:49:14 -0500

Got some screenshot of Camera Obscura with our new player sprites. I plan to show a video as soon as all the frames are done.

In other news, the Video Game Development Club just released its first for-sale game on XBox Live! The game is Nucleon - it's a pretty intense puzzle/arcade/action game and several of the people on the Camera team are addicted to it. Check it out here (it's only a dollar!). We've very interested in seeing how it does - personally I think that XBox Live gives indie games the short end of the stick. All indie games on the marketplace are only a dollar, which puts some honestly bad games on par with well-done ones like Nucleon and the surprisingly addictive and interesting I MAED A GAM3 W1TH Z0MB1ES!!!1, but we're still interested to see how Nucleon does.

Camera Obscura Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 12 May 2011 19:08:55 -0500

Thought I should post what kind of progress is being made on Camera Obscura, as that is my focus as far as game programming right now. We just won $100 at UCI's Game Jam Popular Choice competition, at which 40-something people voted our game as one of the best shown (the second place team received 27 votes!) This should cover the fees associated with the game's eventual publication to XBox Live. Programming progress is quite good - we've fixed almost every known bug, and polished up a lot of the early levels to help teach players the game's mechanics.

Inspiration for this part of the game is coming from games such as Portal and Braid: we want to ease the player into each of the game's mechanics, making him or her figure out how they work, guiding them to the solution and slowly giving them more and more to think about on their own. And we want to make absolutely minimal use of text boxes: show, don't tell.

Nonfunctional Games

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 17 Apr 2011 12:38:36 -0500

It seems that Windows 7 Service Pack 1 broke all games made in DarkBASIC Pro, which would include all of those posted here. I'll need to recompile all of them with the fixed DBP compiler and reupload them. If you get an error saying that the "parameter is invalid", try downloading the game again.

Game Jam Press and Camera Obscura Download

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 14 Apr 2011 15:59:59 -0500

The UCI Game Jam was featured rather prominently in the Orange County Register this week, and my team (Rainbow Dice Games) was interviewed for the article (though I was at class). They provided download links for the four completed games that came out of the competition, so I guess I can't hide that any more: link! Remember that this is one week of work, and we plan to continue improving our game possibly into something saleable.

Spring Gam Jam END

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 12 Apr 2011 02:55:52 -0500

This week has been so busy I didn't even have time to write a post in the middle of it. But Game Jam is over and our game is done! It turned out absolutely awesome, and the original idea was a great one. There is talk of continuing to work on it and release on the XBox Live Arcade. I will try to post more info about the game itself soon.

Spring 2011 - Game Jam Again

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 05 Apr 2011 14:54:57 -0500

It is Spring quarter here at UCI, and that means another Video Game Development Club one-week Game Jam! The teams are set up and every game must have something to do with shadows. Our team has the basics of a game idea pounded out, and by next Monday at 11:00 it needs to be functional. See you then ;).

That TPS, Break, Part 2

webmaster@brianmacintosh.com (Brian MacIntosh) — Thu, 24 Mar 2011 19:42:14 -0500

Well, it's the second day since my last post. I had a lot of problems with playing two different animations on the same object (for example, making my player's lower body play a walking animation while his upper body pointed a gun). I tried about four different ways, and all of them were bugged in some unfathomable way and didn't quite work right. I fell back on using two seperate objects, one with the lower body hidden and one with the upper body hidden, which I thought would create a terrible seam. Fortunately, it seems to be working okay (just wait 'til I get to crouching).

Anyway, I should show some of those promised screenies:

So, outside of struggling with the animation, I put in grenades and started on the AI. It's gonna be AI for the next few days, I think.

Spring Break, Third Person Shooter Part 1

webmaster@brianmacintosh.com (Brian MacIntosh) — Tue, 22 Mar 2011 15:06:53 -0500

It's noon on Tuesday of Spring Break week, and I spend almost all of my waking hours since Sunday morning sitting here programming. This is the project I've mentioned a few times before. The plan is to make a tactical, squad-based third-person shooter. The game will play in a number of self-contained "missions", each of which will be characterized by an important "planning phase" and then an "execution phase". During the planning phase, the player will complete a scouting mission (perhaps some sort of mini-game) to acquire information about the area the mission is targetted at (blueprints and maps and such), and will use it to lay out a rough plan for his squad members to follow. Then they and their squad complete the mission in the 3PS part of the game. The most notable elements in this part will be the ability to climb on and over walls and obstactles, and enemy AI and difficulty that should enable and encourage the use of stealth.

So far, all of the work has been on the shooting part. I have the basics (movement and collision), some very fun particle effects (flying shell casings, dropped clips, and bullet holes and impact effects), and a simplistic climbing system that allows hanging from and climbing onto map elements (just a few big boxes so far). I will post screenshots tomorrow, by which time I hope to have the split animation system worked out so the player character will stop looking like some kind of crazy contortionist.

Soul Hunter

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 28 Feb 2011 14:20:23 -0600

School is busy filling my head with binary trees, hash maps, and recurrence relations at the moment, but when spring break arrives I intend to put some more work into Nebula and my as of yet unnamed tech demo. In the meantime, I thought I'd plug a game that has been in progress in DarkBASIC Classic for an impressive amount time: SoulHunter by zzz (Jarl Larsson), a dark Zelda-esque RPG. Jarl started the game six years ago, and it is just now reaching its Alpha stage, so go check it out!

Those Dam Beavers! Update

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 29 Jan 2011 18:20:21 -0600

An after-competition improved version of Those Dam Beavers is here.

UCI VGDC Winter Game Jam Over!

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 19 Jan 2011 03:11:44 -0600

The UCI Video Game Development Club's Winter Game Jam 2011 ended yesterday. This annual competition within the club requires each team to make a game in one week according to a theme. This year the theme was "pressure". I was a programmer on one of the four participating teams of about 10 people each. It was quite cool to see the game come together over the week as the artists submitted the various assets and the code was assembled. The brainstorming session was also a fun experience involving many great ideas, jumping from genre to genre but usually including beavers with jet packs and bubblegum.

You can get all four games here - I worked on "Those Dam Beavers!".

P.S. We used FlatRedBall and its editor Glue to make our game - sadly I don't recommend anyone else repeat the experience, especially if you're trying to use version control. I do love C# and XNA though.

Subscribe!

webmaster@brianmacintosh.com (Brian MacIntosh) — Sat, 15 Jan 2011 13:07:16 -0600

Just finished up a subscription system for this blog and for the posting of new projects - get an e-mail whenever I make a new post or, more importantly, upload a new project! Click the green icon above!

There is also the RSS feed to subscribe to.

Port Apollo Completed!

webmaster@brianmacintosh.com (Brian MacIntosh) — Wed, 29 Dec 2010 11:51:47 -0600

After a few bug fixes, Port Apollo is done! I'm looking forward to moving on to a new project. See the the Port Apollo project page to download.

Port Apollo Preliminary Release

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 20 Dec 2010 22:19:29 -0600

I've just put up a download for Port Apollo. I'm going to be taking bug reports and maybe some feature requests on this version before I call the project DONE!

Port Apollo - Video Posted

webmaster@brianmacintosh.com (Brian MacIntosh) — Mon, 13 Dec 2010 18:18:00 -0600

A game of medium proportions I started in August is very near completion, so I've put it up here. It's a bunch of 3D, physics-based fun, and there are explosions! There's a video on the project page.

Online High Scores Set Up

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 12 Dec 2010 14:06:00 -0600

Today I thought I'd try to use my nice webspace here to host an online scoreboard system for some of my games. I tested it out with Unterseeboot! and it seems to be working great. Do try it out and fill up the scoreboard :).

Welcome to brianmacintosh.com

webmaster@brianmacintosh.com (Brian MacIntosh) — Sun, 21 Nov 2010 09:20:00 -0600

The site still needs a lot of work, obviously. Some of the most immediate tasks:

- Put a PHP blog here instead of all this text (though if you're reading this, that's done!)

- Prepare more of my games and programs for distribution and upload them for your downloading pleasure