A Link to some MEL and Python work

I’ve been contacted a few times from people interested in some MEL and python work that I did a few years ago for a VSFX class I took while at SCAD. I thought I would link to the content here in case anyone is interested. I really liked working with MEL and Python, and would like to continue creating tools using them.

Mel and Python Site

Space Cowboy Game Jam – Gravity Bloke

Gravity Bloke

Recently I was able to take part in a two week long game jam. The longer format afforded us much more time to plan things out and make better decisions than racing to finish in 48 hours, and it made the experience much smoother and less stressful. This time the theme was “Space Cowboys,” definitely the most straightforward theme I’ve ever done a game jam for. So we started out working on a 2D platformer where your goal was to explore the interior of a space ship and collect the bounty on a specific enemy, either by shooting him or using your lasso to capture him and drag him back to your ship.
The game we finished with was a bit different, but I think it ended up becoming much more original and fun. As we got the core mechanisms working, we focused on what was fun about jumping around, lassoing enemies and dragging them around. Dragging them around the environment was the key feature that we found to be the most fun, so we changed our design to make lassoing enemies the central mechanism of our game. Long, explorable levels gave way to a very simple arena style level, and the goal of the game became to achieve a high score by shooting or lassoing as many enemies as you can within the given time limit. Parts of the level are also influenced by different gravitational forces. Certain parts of the level have reversed gravity, while others have very light gravity.
Points are awarded to the player each time he or she either shoots an enemy, or drags one to the capture area. As capturing takes longer, more points are awarded for a capture than for killing an enemy. In addition to the standard enemies, a certain enemy with a higher bounty is always present in the level. After this enemy spawns, his bounty is steadily decreased over time. Players are rewarded for finding the target enemy quickly in order to claim the highest bounty.
As it was a game jam game, there are still plenty of bugs, as well as many areas that could use refinement. Still, it can be played in its submitted state can be downloaded and played here. As I said, it has plenty of bugs, but that’s to be expected from a 2 week build.  Also, I’d recommend playing with a controller if you can.

If we continue work on the game, which I plan to, I’ll update this post with updated versions.

NCARB Follow Up

Well, a few short months have gone by and we’ve been continuing work on our NCARB project with the Architecture Department.  For the summer quarter we had a much smaller team, numbering about 6 or so, with others dropping in on occasion to help out with specific tasks.  Our decreased manpower definitely took its toll on our asset output, but we were able to focus in on our game’s issues as well as features we hadn’t gotten around to implementing.

NCARB August build

Now, I know what you’re thinking.  Based on the screenshot it looks really similar to the one from three months ago.  True enough, the main setup looks pretty familiar.  Though the main interface and set dressing will soon be seeing another pass soon, the main changes this quarter came in the design.

Necessary Changes — 

After a few months of working with the architecture students to create scenarios for our game, we noticed our scenario writers were struggling with creating new content.  The issue emerged as a result of our scenario system, and the way each scenario had to be designed in order to work within that system.

The way our system originally worked, a scenario consisted of three possible ‘tracks,’ or sets of scenes that players could follow as they went along.  These tracks weren’t necessarily linear however because it was possible for a player to jump from one track to another after any given scene.

scenario flowchart

It broke down like this:

– The player would select his or her chosen response to the given scene

select choice

– That player would be awarded positive or negative points in seven categories based on his or her choice

value points

– Those points were then compared to another set of values for those seven categories which represent the client’s desired outcome.  This determines an umbrella “Client Satisfaction” value.


– This value then determined which of the three possible scenes the player was given next.

cs values

We tested this system pretty thoroughly and found it worked well to move the player through the scenario.  The issue came about not as a result of the system not working, but our three path structure and evaluation after each scene meant that the premise of a particular scene could not be a continuation of a previous scene because the player could conceivably arrive at that scene from anywhere.  This became a problem for our architecture friends as well as our chief writer because each scene had to be pretty much agnostic of anything that came before it.

In the end we decided it was best for the project to switch to a more open ended branching structure for our scenarios.  This was not an easy decision to make, as it meant throwing out the system we had developed, and reworking a lot of the coding I had done.

So we went back and came up with a system that allowed our writers to create scenarios as with as many branching paths a they wanted.  We did however restrict them to the three choices per scene format.  This was done for a number of reasons, a consistent markup format and interface being among them.

Office Relations — 

Working in an office isn’t just about finishing your work.  interacting with your co-workers is a necessary part of working anywhere.  We’ve finally gotten around to fully integrating our co-worker interaction mini game.

We have four different NPCs that will approach your desk.  depending on which pose they appear in, they could offer you advice, ask for help, or they could want to share the latest gossip with you.  You can choose to ignore them or talk with them, but doing so will have an effect on your time management and office politics.  The player has to balance being a good coworker without wasting too much time on idle gossip.   The intricacies of the co-worker mini game were worked out by Hayley, who stayed on with us to help with design work.


One of the most important requirements of an effective gameplay system is providing feedback to the player.  Without showing players the impact of their decisions, how can they be expected to understand and eventually master the system?  At the beginning of the summer we decided that the system we had devised for showing the consequences of players’ choices wasn’t working.  The original system featured items in the environment reacting in a positive and negative way depending on the impact of players’ choices.  Make a choice that negatively impacts the environment and a plant in the office will start to wilt.  The problem was that we found the connection between choices and the objects in the office weren’t obvious enough.  It wasn’t immediately apparent that objects were animating for a reason and not just at random.  We knew we needed something more immediately obvious,  thus the icon bar was born.  The icons on this bar will turn green or red based on player decisions.  They also get more or less saturated based on the player’s score in these areas.  This gives players an idea of how they are doing without giving them the exact numbers.

There’s still work to be done, but we’re definitely making progress.  The different systems are finally starting to come together, and the game is improving with each build.

NCARB grant project – Studio DAG

I recently got the opportunity to work on a joint project between the SCAD architecture department and games department. Our friends in the architecture department applied for and received a grant with the NCARB to develop an interactive game that teaches professional practices to architecture students.

When I came aboard the project, the core system had already been worked out. The basic principle is that you are given a scenario made up of individual scenes- basically decisions that need to be made. Each scene presents you with three possible choices and you must choose the course of action you feel is best. These choices move you down one of three tracks as you move through the scenario.

Another grad student, David Reardon, and I together with our professor worked out that each decision should influence your total values in one of six categories: Communication, Ethics, Environment, Ethics, Politics and Public Relations. As you make decisions, you are constantly being evaluated based on these categories, while also trying to keep the client happy. The interesting dynamic comes into play when these two factors are in opposition. The client usually values time and finances, but if you make too many decisions that negatively impact another category you can still fail, even if the client is happy.

Dave and I have been further developing our core system, while I’ve also been leading the game’s development using Unity. With the help of a class of students, we’ve managed to create develop our initial build.

NCARB June Build

We’ve been working with a larger development team than I’m used to, which has been really great.  We’ve managed to generate a lot of content in just 10 week.s  I just wish we had more programmers.  Still, we managed to produce a vertical slice of Studio DAG (not the title I would have given it) in a very short period of time.

Some things aren’t quite finished, as you’ve no doubt noticed by the giant glaring “character name” in the image above, but those will hopefully get polished up pretty soon.  Myself and a few others will continue work over the summer, so hopefully we can continue work on some of the systems we developed but didn’t get a chance to implement.


Comrade’s first Steps

I recently completed a class that taught programming with Flash.  For the final we had to make a simple game.  Having only a few weeks to work on it, I made a simple SHMUP featuring a character I had on my mind for a while named Comrade.

Comrade SHMUP

If the sprites look a bit big for a SHMUP and a dog shooting lasers seems a bit weird it’s because I didn’t really design this character for a SHMUP.  My plan for Comrade is to create an exploration based 2D platformer with him as the main character.  Expect to see more of Comrade as that project continues.  I should also note that this was my first time doing any real pixel art work, so I know I have some improvements to make.

Hello and Welcome

Welcome to my blog. Here you can expect to find things related to what I’ve been doing and thinking about. Most of these posts will probably be related to game design concepts, but I expect there’ll be a few development updates and such here too. Feel free to comment on anything you may find interesting.