I admit it. I’m a pretty lazy guy. I don’t have much patience for mind-numbingly repetitive tasks. They bring me down. Editing my Outlook calendar every day is simply a waste of time in my opinion. I figured that there must be a way to automatically create appointments through some kind of script. Then I wondered if Ruby could help.

After doing some quick research, I found out that it’s actually quite easy to connect Ruby and Outlook. This is done through Microsoft’s Object Linking and Embedding (OLE) protocol. I wasn’t able to find a definitive tutorial for Ruby and OLE, but there is enough information scattered about the internet to get a simple script up and running.

Modifying an Outlook calendar from Ruby basically boils down to knowing how to do three things: 1) Opening a context to Outlook, 2) Connecting to the “Calendar” (as opposed to the Mailbox, Contacts, etc.), and 3) Creating/Listing appointments. I learned how to do all of this from the following sources:

1. Controlling the Outlook session using OLE
2. Outlook Appointments with Ruby
3. Automating Outlook with Ruby: Sending Email
4. win32ole Ruby Standard Library Documentation

Those links provided enough information for me to write a script that connects to my calendar and prints out all of my existing appointments. It’s not much, but as a proof-of-concept it’s not bad.

And here’s the code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115

#
# 28 June 2010, Phillip Weisberg <fettuccini@qiroka.com>
# License: Creative Commons 3.0 Attribution 3.0 Unported
# Purpose: Demonstrates how to read/add items in a Microsoft Outlook calendar
#
# References:
#   Controlling the Outlook session using OLE: http://downloads.sybase.com/codexchange/powerbuilder/404/PowerBuilder_-_Controlling_the_Outlook_session_using_OLE.htm
#   Outlook Appointments with Ruby: http://www.artima.com/forums/flat.jsp?forum=123&amp;thread=111926
#   Automating Outlook with Ruby: Sending Email: http://rubyonwindows.blogspot.com/2007/07/automating-outlook-with-ruby-sending.html
#   win32ole Ruby Standard Library Documentation: http://www.ruby-doc.org/stdlib/libdoc/win32ole/rdoc/index.html
#
 
#------------------------------------------------------------------------------
# Requires
#------------------------------------------------------------------------------
 
require 'win32ole'
require 'date'
 
#------------------------------------------------------------------------------
# Struct Definitions
#------------------------------------------------------------------------------
 
Struct.new( "AppointmentInfo", :Subject, :Body, :Start, :End, :ReminderSet )
 
#------------------------------------------------------------------------------
# Instance Variables
#------------------------------------------------------------------------------
 
@outlookApplication = WIN32OLE.new( 'Outlook.Application' )
 
#------------------------------------------------------------------------------
# Methods
#------------------------------------------------------------------------------
 
# --- Creates a new appointment in Outlook ---
def CreateOutlookAppointment( appointmentInfo, categories )
  # Verify that the appointment ends after it starts (Note that the data of an all-day event appears to end before it starts)
  if ( appointmentInfo.End <= appointmentInfo.Start )
    puts "[createAppointment] Warning: Appointment creation aborted due to end date before start date."
    return
  end
 
   # Create the Outlook application item
   appointment			= @outlookApplication.CreateItem( 1 )		# 1 = Creates an appointment
   appointment.Subject		= appointmentInfo.Subject
   appointment.Body		= appointmentInfo.Body
   appointment.ReminderSet	= appointmentInfo.ReminderSet
   appointment.Start		= appointmentInfo.Start
   appointment.End		= appointmentInfo.End
   appointment.Categories	= categories
 
   appointment.Save
   puts "Created Appointment: [#{appointment.Subject}] at #{appointment.Start}"
 end
 
# --- Finds a listing of all appointments on the specified date from a list of existing appointments ---
def FindExistingAppointmentsForDate( existingAppointments, dateStart )
  appointmentsForDate = Array.new
  existingAppointments.each { |currAppointment|
    if ( currAppointment.Start.year == dateStart.year ) and ( currAppointment.Start.month == dateStart.month ) and ( currAppointment.Start.day == dateStart.day )
	    appointmentsForDate.push( currAppointment )
	  end
  }
 
  return appointmentsForDate
end
 
# --- Loads all of the existing calendar appointments into the array @existingAppointments ---
# --- TODO: Load recurrences as appointments (currently, they are ignored) ---
def LoadExistingAppointments
  namespace = @outlookApplication.GetNamespace( "MAPI" )
  ole_folder = namespace.GetDefaultFolder( 9 )  # 9 = Calendar
  numItems = ole_folder.Items.Count
 
  existingAppointments = Array.new
  for idx in ( 1 .. numItems )
    currItem = ole_folder.Items.Item( idx )
	  dateStart = Time.local( currItem.Start.split("/")[0], currItem.Start.split("/")[1], currItem.Start.split("/")[2].split(" ")[0],	currItem.Start.split(" ")[1].split(":")[0], currItem.Start.split(" ")[1].split(":")[1], currItem.Start.split(" ")[1].split(":")[2])
	  dateEnd = Time.local( currItem.End.split("/")[0], currItem.End.split("/")[1], currItem.End.split("/")[2].split(" ")[0],	currItem.End.split(" ")[1].split(":")[0], currItem.End.split(" ")[1].split(":")[1], currItem.End.split(" ")[1].split(":")[2])
	  tempAppointment = Struct::AppointmentInfo.new( currItem.Subject, "", dateStart, dateEnd, false );
	  existingAppointments.push( tempAppointment )
  end
 
  return existingAppointments
end
 
#------------------------------------------------------------------------------
# Main Program
#------------------------------------------------------------------------------
 
# --- Load all existing appointments and print the contents ---
puts "-----[All Existing Appointments]----------------------------------------"
existingAppointments = LoadExistingAppointments()
existingAppointments.each { |existingAppointment|
   puts "Existing Appointment: [#{existingAppointment.Subject}] at: #{existingAppointment.Start}"
}
puts "------------------------------------------------------------------------\n\n"
 
# --- Find all appointments for a specific day and print the contents ---
puts "----[Existing Appointments Today]---------------------------------------"
dateToday           = Time.now
appointmentsForDate = FindExistingAppointmentsForDate( existingAppointments, dateToday )
appointmentsForDate.each { |appointmentForDate|
   puts "Existing Appointment: [#{appointmentForDate.Subject}] at: #{appointmentForDate.Start}"
}
puts "------------------------------------------------------------------------\n\n"
 
# --- Add an hour long appointment to the Outlook calendar (starting from the current date/time) ---
startDate       = Time.now
endDate         = startDate + 3600  # endDate is one hour after the startDate
newAppointment  = Struct::AppointmentInfo.new( "Example Subject", "Example description", startDate, endDate, false );
CreateOutlookAppointment( newAppointment, "work, school" )
 
puts "DONE"

The code demonstrates how to list all existing appointments in an Outlook calendar as well as how to add new ones programmatically. As a note, this script does not account for recurrences (appointments which repeat) or all-day events. However, it does provide a starting point for taking control of your Outlook calendar through Ruby.

Dad Strength is a comedic beat ‘em up video game modeled after old-school titles such as Double Dragon and Final Fight.  In this postmortem, the game’s development process will be examined in depth.  Dad Strength was developed over the course of two years, and luckily a developer’s diary was maintained throughout this time.

I. Music-based Brainstorming

Music is an incredibly inspirational catalyst for my imagination.  There are particular songs whose moods alone can convey a rich visual representation, and I often find myself puzzling over how one might adapt these into an interactive medium such as a video game.  In fact, most of the game play mechanics I have designed find their origins in the attempt to integrate music and sound into an interactive form without diluting the identity of the music.  The goal is therefore not quite a holistic medium; Players should be able to enjoy the music as a separate experience from that of playing the game.

Lately, I’ve been increasingly interested in the do-it-yourself (DIY) mentality. My friends and I often write and record our own songs, and sometimes the results are quite poignant (to me, at least). My brother in particular writes some fairly unique music.  He came to visit me in Washington D.C. during the summer of 2007, and we wound up creating a few short loops in Garageband using existing samples.  It was nothing more than automatic creation through experimentation, but the results spoke clearly to us both.  In listening to what amounted to nothing more than a few seconds’ worth of music, we could wholly conceptualize a simple, beat ‘em up video game reminiscent of those of early 90’s.  We explored our imaginations for exactly what kind of game the music could suit, and the foundations for Dad Strength were soon born.

II. Design, Pre-production, and Development

The initial design for Dad Strength was very minimalistic.  The game would consist of the main character, two or three enemy characters, a scrolling background, and possibly a blunt weapon that could be picked up and swung about.  When thinking about game development, I generally try to wear a programmer’s hat in order to maximize code reuse whenever possible.  I realized that if Dad Strength was designed carefully, many of its components could be slightly altered for re-use in other game genres such as a 2D fighting game, side-scrolling platformer, or vertical-scrolling space shooter. I kept this in mind while sketching out each of the game building blocks such as the character entity and the health bars.

In order to save time and avoid relying on programmer art, it was decided that sprite-sheets would be developed by filming live actors and extracting key frames.  The actors were filmed performing a variety of motions before a green screen.  The film was then digitally edited using a chroma key to extract the characters from the background.  This approach worked well and also lent itself to creating sprites whose image fidelity fit within the game’s 16-bit nostalgia aesthetic.

There were many times during development that, due to various technological problems, I felt like a decisive barrier had been reached.  In fact, there were spans of months where no progress would be made at all, which was quite depressing.  From time to time, I would entertain the idea of calling it day.  During these slumps, it became increasingly difficult to become motivated about the final product when it seemed to be nothing more than a concept.  However, I was fortunate enough to have had a continuous flow of positive support from friends and family.  Coupled with the raw desire to play the game myself, I found the energy to follow Dad Strength’s development to completion.  Of course, sacrifices and concessions had to be made during the course of its development, yet it is incredibly satisfying when a project surviving on passion alone is finally released for others to enjoy.

III. What Went Right

Comedy.

The game is, in many ways, a parody of the simpler beat ‘em up games of the early 90’s.  There is literally no back-story, character development, nor plot to be found in Dad Strength.  The game stars a middle-aged father figure fighting random foes (of which there are apparently a full supply of identical twins) for no specific reason.  The justification for developing this game can be boiled down to wanting to add a strong entry in my personal game development portfolio, and the game makes no attempt to hide this.  It is a simple game, and its essence lies not in revolutionary game-play nor stunning graphics; It is primarily a demonstration of my programming abilities in the guise of entertainment.

The premise of the game is absurd enough; However, the dialog acts as another supporting pillar of its comedy.  The game opens with the FBI anti-drug warning so commonly associated with arcade cabinets of the 80’s.  The titular character then saunters across the screen and promptly warns the player by saying, “Because I said so!”  In the first few seconds, the tone of the game is established and continues all the way through enemy death cries such as “Et tu, Dad?”.

The game is truly a one-dimensional beat ‘em up in the sense that the player can choose to move left or right along the horizontal axis yet has no control over the vertical axis.  To keep players from being bored or frustrated with this design choice, it was necessary to make the content engaging and justify repeat playability. I chose to achieve this through a mixture of comedy and absurdity.

IV. What Went Wrong

In general, I wrote no technical specification documents to guide the development of Dad Strength.  There were but a few well-defined goals, milestones, and self-imposed deadlines to provide perspective on its progress.  This was largely due to the fact that Dad Strength was a project being developed on weekends and during lunch breaks.  Furthermore, I was developing the underlying technology in tandem with the game itself.  Dad Strength runs on the SFII90 engine whose development goals changed specifically to meet the vague design goals of a side-scrolling game - namely Dad Strength.

A significant consequence of having but a page of technical guidelines was the continuous miscalculation of time requirements.  For example, the character artwork was captured using live video in the effort to save time associated with creating detailed sprite artwork.  Nevertheless, the art pipeline used for processing video data to a final sprite-sheet took no less than four months.  Regarding the programming side of production, better and more robust methods of implementation were constantly being discovered during development, and the fundamental building blocks of the game were revised multiple times.

V. Lessons Learned

Throughout the development of Dad Strength, a number of my friends were eager to hear of its progress.  Some of these friends are incredible artists and others seasoned coders.  In retrospect, I feel that I should have asked them to lend me their expertise and, in doing so, matured the Dad Strength development team from a one-person project to a small team of three or four with specialized skills.  This would have undoubtedly decreased the production time and created an enjoyable team dynamic at the same time.  For subsequent projects of a comparable scope, I intend to work toward making the process a more collaboratively-driven effort.

Speaking specifically to the game’s programming process, I have found that after deciding upon the core game mechanics, the programming itself should focus on creating a library of reusable, extensible components.  In essence, this is akin to creating a level editor as opposed to a set number of levels.  Keeping in mind the “big picture” is crucial for when design documents change and it becomes necessary to modify or scrap the content of any previous iterations.  Case in point: The Ruby scripts for Dad Strength were completely re-written at least three times.  Each time, the design became better organized, less inter-dependent, and easier to maintain. The cost I paid for each revision was a few more months in a world without unjustified Dad on goon violence.

For those interested, Dad Strength may be downloaded from here: Dad Strength.

VI. Supplementary Media

The following is a collection of Dad Strength related media.  Most of the media provided highlight the development of the in-game sprites and associated hit detection logic.

VII. Miscellaneous Dad Strength Information

When building an executable under Microsoft Visual Studio (either the 2005 or 2008 edition), an accompanying manifest file is generated.  The purpose of this file is to describe various dependencies of the executable such as DLLs.  The manifest file is typically baked directly into the executable itself, but alternatively it can exist as an external XML file.  In externalizing an application’s dependency information, developers can explicitly control which versions of the dependent files are to be used.  One major benefit of this design is that various versions of a dependency can exist simultaneously (Side-by-side assemblies as Microsoft calls them) and thus different programs need not use the same version of the dependency files.  This is a great idea in theory as it would eliminate the problem of keeping system DLLs in sync, a process affectionately known as DLL Hell.  However, there are still a few quirks of manifest files that can drive developers and users alike mad.

For the past few years, I’ve been developing a 2D video game engine called SFII90.  The engine was initially developed under Visual Studio 2005 on Windows XP and later migrated to Visual Studio 2008.  When the initial release was ready to be deployed, I ran into a few problems running the application on other operating systems (specifically Windows Server 2003).  Despite installing the VS2005 redistributable components on these systems, I was greeted with error dialogs similar to the following:

After learning that the problem was due to a misconfiguration regarding the application manifest file, I spent quite some time searching online for suggested resolutions.  What I eventually found was that I was suffering from a few issues.  Most notably, the manifest file required msvcr80d.dll (the debug version of the C run-time library), although this was not being used by my application nor was it included in the redistributable package (Microsoft only allows release mode binaries to be distributed to users).  I used a very helpful tool known as Dependency Walker to verify that the application did not require the debug library:

I could confirm that the application did not rely on the debug CRT library msvcr80d.dll.  Regardless, every time I built the application, the manifest listed it as a dependency.  I finally realized that the application itself did not require the debug library but that some of its dependents were in fact dependent on the debug library.  The project included a few DLLs that I had built from source such as FreeType and Vorbis.  These had apparently been built as debug libraries under VS2005.  Even after migrating to VS2008, these libraries required the VS2005 debug CRT library which explained why the main application was requesting the debug library.  After rebuilding all of the DLLs in release mode under VS2008, the references to msvcrt80.dll in the manifest file disappeared.  At that point, my external manifest file “SFII90.exe.manifest” looked like the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

The important part of the manifest file above is where the name of the dependent manifests and their versions are defined.  In this case, the name of the sole dependency is “Microsoft.VC90.CRT”, so the accompanying manifest file must be “Microsoft.VC90.CRT.manifest”.  This file can typically be found as part of the Windows side-by-side assembly manifests under C:\Windows\winsxs.  It is critical that the version of the CRT manifest matches that defined in the main application’s manifest (in this case, the version is 9.0.21022.8).  The following illustrates an example of the contents of such a manifest file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable></noInheritable>
    <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    <file name="msvcr90.dll" hashalg="SHA1" hash="e0dcdcbfcb452747da530fae6b000d47c8674671"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>KSaO8M0iCtPF6YEr79P1dZsnomY=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcp90.dll" hashalg="SHA1" hash="81efe890e4ef2615c0bb4dda7b94bea177c86ebd"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>ojDmTgpYMFRKJYkPcM6ckpYkWUU=</dsig:DigestValue></asmv2:hash></file>
    <file name="msvcm90.dll" hashalg="SHA1" hash="5470081b336abd7b82c6387567a661a729483b04"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>tVogb8kezDre2mXShlIqpp8ErIg=</dsig:DigestValue></asmv2:hash></file>
</assembly>

All of the manifest files and DLLs being referenced should be placed in the same directory as the main application.  To summarize, dealing with manifest files is not too difficult, but due to seemingly erroneous dependencies and version incompatibilities, they can be intimidating to configure properly.  For this reason, I suggest externalizing the manifest files (this can be done in Microsoft Visual Studio by naviating to Project Properties -> Linker -> Manifest File -> Allow Isolation and setting the value to “Yes”) and resolving dependency issues using Dependency Walker.

For those following the most current video game releases, MadWorld should need no introduction.  In a nutshell, Madworld offer players a highly stylized, film noir environment in which to creatively torture and execute an assortment of grotesque and supernatural foes.  The central controversies surrounding the game relate to its sole target platform - the Nintendo Wii.  Before the game’s release, critics and fanboys have mainly argued the following points:

1. The Nintendo Wii is not technically powerful enough to provide the intended experience.
2. The family-friendly Wii will become a liability for children due to MadWorld’s vulgarity and excessive violence.  This could also create an opportunity for similar games to be published without Nintendo showing any concern for morality obligations.

Simply and objectively put, the first argument is fallacious because the MadWorld developers specifically chose Wii as their target platform due to its unique motion controls (see: Why MadWorld is Wii-only).  The second argument is dismissible due to the existence of Mature Wii games (Manhunt 2, No More Heroes) as well the illogical implication that Nintendo has a social responsibility to prevent adult content from gracing its consoles.  The “Mature” rating on MadWorld’s cover should be the first clue to parents of young children that Super Mario Galaxy might be a better choice.

MadWorld was the first release developed by Platinum Games, a relatively new company formed by many of the ex-members of the dissolved Clover Studio (Viewtiful Joe, Okami).  Since I’m a huge fan of their Playstation2 beat ‘em up throwback God Hand, I’ve been eagerly awaiting MadWorld’s release since it was unveiled last year.  However, when the game was released, my Wii was inaccessible; My father had kidnapped it to play Guitar Hero World Tour.  At the same time, I was facing the decision to have surgery to correct a level III+ acromioclavicular separation.  The total time needed to completely heal from surgery and rehabilitation is 4-6 months, so it wasn’t a light decision.  With the surgery date looming only three days away and no way to play my copy of MadWorld, I went insane and I did the only thing I could.

I had waited patiently for a few years so that I could play Platinum’s follow-up to Okami, and the thought of waiting another two or three months made me both angry and frustrated.  Even knowing that I’d only have the chance to play MadWorld for a few hours before having surgery, I opted to buy a Wii and play what I could with the short amount of time remaining.

Initially, I was very impressed with the production values, but after 15 minutes or so, I became disappointed (and borderline bored) with the gameplay.  I soon realized that this was because I was unconsciously expecting God Hand 2, of which MadWorld certainly is not.  Whereas God Hand is frantic and demands fast reflexes, MadWorld is a bit more strategic and rewards players for stringing together brutal combo attacks.  Two other fairly large aspects of this game that deserve mention are its self-referential hip-hop soundtrack and its over-the-top sportscaster banter.  While I appreciate the freshness of these aural elements, they tended to grate after much repetition.  Thankfully, Platinum has allowed the user to customize the volume of each individual auditory stream.  Playing through MadWorld with only its sound effects is in some ways eerier and more satisfying.

After only a few hours of game play, MadWorld did grow on me.  I was able to complete half of the game in about two and a half hours, so my experience mirrors that of many critics whom note the brevity of the game.  The game itself is not without flaws and annoyances, but it deserves a solid B for its style, direction, and relentless originality.  I wouldn’t say that MadWorld is a “must play” game for Wii, but it is certainly a gem for those seeking a fun, polished beat-em-up with a sadistic streak.  Platinum Games looks to have a bright future as innovative developers, and I can’t wait to see what other worlds they can create.  So, was it worth buying a Wii simply to play MadWorld for three hours?  Surprisingly, I’m going to say “yes“.  Although, it’s possible that it’s just the painkillers talking.  84/100

While developing a humble beat ‘em up game (an homage to such classics as Final Fight and Turtles in Time), I found myself in need of a way to organize various scenes.  The game would start with a loading screen, transition into a short narrative, and finally cut to the title screen.  Once the actual gameplay began, another scene would be needed to keep track of the entities, images, sounds, and other game-related objects for stage one.  In keeping with the ethics of object-oriented programming, I decided to make the scenes themselves objects by creating a scene entity with methods for loading, activation, deactivation, and unloading.

Lately, I’ve been wondering if I haven’t developed a bit of ADHD.  I have a handful of game ideas that I want to explore and the list keeps growing.  The problem I’m facing is how to choose the best ideas and spend time turning them into projects.  When I completed the scene entity (which took very little time), I made the decision to design a small game to test its usefulness (which took much more time).  It turns out that the scene entity has very little to do with the final game, yet I am left with something much more satisfying.

It took around 12 hours of development (over the course of a month) to create a small game called beatboy.  The fundamental principle of beatboy is that it is not actually a video game.  I consider it more of a toy than a video game.  There are no goals, no scores, no time limits, and is meant for players to customize it with their own sound samples to tailor their own experiences.  I was inspired to create such a game by observing how a 4-year-old attempted to play a video game; it seemed that getting a colorful reaction to pressing buttons was more fun than trying to learn the rules.  I wanted to create a game that a child could idly “play” and yet somehow still appeal to adults.

Of course, there are already game developers aiming to explore unconventional gameplay, abstract themes, and experimental styles.  Using these types of games as reference points, I have tried to keep beatboy minimalist and usable.  In particular, I find the works of the following game designers fascinating:

Electroplankton / Nintendo DS / 2006 / Designer: Toshio Iwai-san (岩井俊雄さん)

Noby Noby Boy / Playstation3 / 2009 / Designer: Keita Takahashi-san (高橋 慶太さん)

I Wish I Were The Moon / PC / 2008 / Designer: Daniel Benmergui

The Marriage / PC / 2007 / Designer: Rod Humble

It is a very exciting time for experimental game design.  The video game industry as a whole is undeniably maturing at an incredible rate, and I feel that these games illustrate the stepping stones into a new arena of gaming.

SFII90 - C++ and Ruby Video Game Engine

My name is Phillip Weisberg and I’m a software developer in the Washington, D.C. area.  Welcome to fiber-optic megawatts!  This blog will focus mainly upon video games - from reviews through development and anything else along the way.  Today’s topic is SFII90 - a free video game engine that I developed in C++ and Ruby and licensed under the GNU LGPL 2.1.  Before I jump too far ahead, let me first give you a little background about myself and the how the engine came to be.

I’ve always been interested in designing and producing video games.  I made a few demos in 2005, but I wasn’t satisfied with how horribly inefficient they were; There was almost no reusable code nor consistent design from game to game.  I looked at the top ten or twenty engines available for hobbyists and for some reason or another was not satisfied with any of them.  I thought it might be a good idea to create my own video game engine (despite some foreboding comments on www.gamedev.net), so I started by designing a small system that could draw sprites from bitmap files and load OGG Vorbis files.  It was… better, but still not very good.

In the winter of 2006, I decided to take a serious approach at researching how to design a modular, easy-to-use video game engine.  I considered as many aspects of the engine as I could before commiting to development specifics such as languages and target platforms.  After about a year of scribbling notes on pieces of scrap paper and pizza boxes, I felt I was ready to start coding.  One of my core goals was to design a system that was as straightforward as possible and encouraged developers (and even players) to toy with the game code itself and see what they could discover.  If I structured the engine and scripting language API as clear as possible, perhaps it could intrigue a few gamers into modifying/customizing the games they play.  With this in mind, I decided to sacrifice speed for the sake of simplicity.

I knew that programming games with my engine would also need to be fun.  How could that be possible?  It just so happens that at that time I was learning a scripting language called Ruby.  Its design philosophy was remarkably similar to mine - focus on the developers, not the machines.  Computers can always get faster.  Memory is cheap.  A high-level programming language should be simple, follow the Principle of Least Surprise (POSS, though definitely related to KISS), and most of all enjoyable!  I found this to be the case when developing with Ruby, so I decided to integrate it into my engine as the scripting language.  I wrote a framework around it to handle entities, device input, and finite state machines.

By the summer of 2008, the engine was in a stable state and was ready to be tested.  A few colleagues and friends of mine suggested forming a game development team to enter the “Games for Health Game Jam”.  The contest focused on creating a game in a 24-hour period that related to personal health and safely controlling one’s body mass index (BMI).  It was sponsored by the Games for Health Initiative and the Robert Wood Johnson Foundation.  There were six teams that entered and competed for a total of $4,000 in cash prizes.  The contest was a great experience and there were a lot of really innovative entries.

Games for Health Game Jam 2008 - Baltimore, MD

After everyone presented their games, the judges exited the auditorium to confer.  They returned shortly to announce that my team and I had won the grand prize for our entry “150 A Day”.  We were incredibly happy to have won the game jam, and I was particularly happy that the game had been developed using SFII90.  It had passed an important test.  However, the experience had taught me a few things about using the engine.  Most notably, it was difficult for other developers to get the hang of it without any documentation.  Since I had always been a lone developer on this project, I definitely neglected this aspect.

For the next two months, I worked on documenting all of the C++ engine as well as the Ruby framework.  I also added a much needed logging utility to tell developers which lines of Ruby script cause problems.  The Game Jam was a great experience because it showed me quite clearly that an engine (no matter how complex or simple) is useless without proper documentation.  I also realized that it would be very helpful to add a set of “common” objects, or entities, to the distribution of SFII90.  There are now classes that are distributed as part of SFII90 for creating animated sprites, frames per second (FPS) counters, and joystick bindings.

So today, after a total of possibly three years, I released the first version of SFII90.  I’m excited to see what people can create with it, and I welcome your feedback and suggestions.  SFII90 has come a long way since being a simple bitmap and OGG audio file loader, but of course there is still much more work to be done.