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

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

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

Blog RSS E-Mail

You are filtering on tag 'post mortem'. Remove Filters
Previous Page | 4 total posts | page 1 of 1 | Next Page

Ludum Dare #29 Complete


May 11th, 2014 @ 2:43
Tags: ludum dare, game jam, post mortem, the legend of the thunder fish, html5, threejs, javascript

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.

Thunder Fish game work in progress.
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.

Thunder Fish game finished conversation system
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.


Permalink

Ludum Dare #27 Complete


September 02nd, 2013 @ 22:26
Tags: ludum dare, game jam, post mortem, the 91st parallel

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.

The 91st Parallel Screenshot


Permalink

Super Pirate Box: 48 hours postmortem


January 20th, 2013 @ 4:12
Tags: game jam, super pirate box, post mortem

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.

Super Pirate Box screenshot

Update: Get the game on the project page.


Permalink

Making Music Games (a programmer's postmortem)


March 20th, 2012 @ 0:39
Tags: music island, post mortem

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!


Permalink


Previous Page | 4 total posts | page 1 of 1 | Next Page