ETC Semester Project - Stempower

Now halfway through my third semester at the Entertainment Technology Center, it's about time I post an update about my current semester project.  Stempower is part of the DARPA Engage project, and we are working to make an educational game for the web using Unity3D based on the research of Stella Vosniadou.  Our goal is to educate third grade aged children about our Earth's day/night cycle.  We're creating a puzzle game called Sleepy Busy Planet that has players rotating the Earth to wake up different characters scattered around the globe who are all working together to build secret projects.  As the game is a web game you can try it now.  Feel free to check back as the semester goes on, we update the public build every Friday when our newsletter goes out.

This semester I am serving as the group's producer and am also still contributing as a programmer.  The lessons I learned about Scrum and Agile Development while an intern this past summer at Schell Games are currently serving me and my team very well as I handle production duties for the group.  I have two teammates who are also programmers, and this is their first semester-long project.  I am taking more of a leadership role on this project and am letting them take point on writing most of the code, while I architect the higher level layout of the code and help them debug as needed. 

SFPC - Summer 2012 Update

It's been far too long since I've written up any updates for SFPC, so here's a double update to try and make up for that!  I may have stayed quiet this summer, but that doesn't mean I wasn't busy!  Originally I didn't think I would have an internship this summer so the plan became "Work on SFPC Full Time", but an offer finally came through in early June to work as a Programming Intern at Schell Games.  I spent a couple months there this summer working with some wonderful people making some very cool stuff that I unfortunately can't talk about, such is life in the land of NDAs and unannounced projects.  While I had less time to spend on SFPC because of the internship, I did end up learning a lot of new stuff and making several new friends in that time, so I'm pretty happy with how my summer went.  I got back into my old groove of working an hour or two a day on SFPC before work each weekday so that I'd still get some stuff done, just not as much as I was planning on.

The first part of the update is in regards to SFPC itself:


I spent a little over 2 solid weeks working on implementing A* pathfinding in the engine so that enemies can move in combat.  There's no AI yet to control how they choose what target to move to or have them inch up when there are no targets in range or anything like that, but this is an important first step.

The second part of the update is the unveiling of a new companion project which will be developed alongside SFPC:


SHEd is my GUI based editor for SFPC.  Built with C# and .NET 4.0, SHEd will eventually be the main content creation and editing application used for building games with the SFPC engine.  For now it supports editing characters, items, and battle animations, but I plan on expanding it to support map editing and scripting as well.

That's it for now, feel free to email me any questions or comments you may have about SFPC and SHEd! 

ETC Semester Project - Spring Entertainment - Complete!

My first year at the ETC and my first client project are now complete!  I was the gameplay programmer on the Spring Entertainment project this spring.  Our client was Seven Springs Mountain Resort, a four seasons resort here in Western Pennsylvania.  We built an iPhone and Android game called Seven's Wild Ride.  It's an advergame that shows Seven Springs ads at the start and is lightly themed to advertise activities available to guests at the resort.  You can check it out in our thirty second teaser and three minute trailer below.

Thirty Second Teaser:


Three Minute Trailer:


It was a lot of work, but I had a blast every step of the way.  The Spring Entertainment team was a great group, everyone was easy to get along with and we all worked well together.  The finished build has been handed off to the client who is in charge of getting it submitted to Apple and Google to be published.  When the game gets released on the app store and Google Play I'll be sure to post about it again so everyone can download it and give it a try.

Shuffle Dungeon - A Hybrid Board/Card Game

For the Freestyle assignment for Jesse Schell's Game Design course at the ETC, we had full freedom to make whatever game our hearts desired and one month to make it happen.  We were free to form groups or fly solo, I opted to work alone on this project.  I designed a hybrid board/card game called Shuffle Dungeon which uses decks of cards to randomly generate a game board for a dungeon crawling experience for 2 to 4 players.  The idea is to have a Dungeons and Dragons like experience that does not require a dungeon master.

I came up with the board generation mechanic very early and liked it enough to build the rest of the game around it, but had some trouble along the way with some of the other mechanics.  I needed to design a system for resolving combat and other encounters that ran very quickly and I threw out a lot of early versions until I got to the system that ended up in the final game: roll a d6, add any temporary or permanent modifiers, then consult the chart on the card.  As Shuffle Dungeon is a card game, I borrowed one of the design themes of Magic the Gathering where the rules of the game itself are simple, but rules that may emerge during play for specific cards are printed on the cards themselves.  This constraint forced me to make those rules as clear, simple, and most importantly, brief as possible so that they would fit on the cards at a legible size.

Since players take turns people sitting idle can get bored, so I wanted turns to go as fast as possible to keep people engaged.  I never quite achieved a level of player interaction that I was happy with, conflict between players is more indirect and subtle than anything.  I worried that open PvP did not suit the combat system well at all and shied away from permitting players to attack each other.  I think that with some further iteration I could come up with something better on that front.  However, I'm fairly happy with the end result.  I could see myself coming back to Shuffle Dungeon some day to polish it even further or perhaps develop an expansion set for it.  Its card game roots make it very modular, adding a deck building element to it could add another fun dimension of play to it.

Final Rules
Final Cards
Playtesting Writeup
Marketing Sheet

Shuffle Dungeon was built using Magic Set Editor. 

Topple! - A Dice Game

For the Dice assignment in the Game Design class at the ETC we had to design our own dice game.  There were few constraints, the game had to include dice in some way while keeping in mind the balance between skill and luck.  I ended up making a game I called Topple! which is a territory control strategy game for three or four players.  Dice are used as much as a means of tracking board state as they are a tool for randomness.   Players fill the board with dice of their color, when opposing dice enter the same square the lower valued die is subtracted from the higher die.  Dice move one square at a time and they "roll" like a cube rolls.  This changes what value they have facing upwards which has interesting effects on both how players attack and defend.  The titular mechanic, toppling, happens when a player moves a large stack of dice; the entire stack falls over (carefully) and each individual die then engages in battle with any other dice it may land on, or restacks with friendly dice.  The game was well received by all of my playtesters in a very early state and I got to spend a lot of time iterating on the smaller details to get it into a fun, polished state before submitting it.

Here's a slideshow of photos with an audio recording I took at one of my earlier playtests:



Here's another video, this time an actual video not a slideshow, but focused on the board not the players:



You can download the rules and playtest writeup here.  If you have enough d6's lying around, you can even try it out yourself.  If you do, send me an email and let me know what you think!

Game Design Elective

In addition to working on our semester-long projects here at the ETC, students also take at least one elective per semester.  This semester I am taking Jesse Schell's Game Design course which so far has been both entertaining and educational!  Our first project was to design a new and improved version of hopscotch, my version of which you can check out here.  It's funny, even such a simple game as hopscotch has a lot of rules to keep track of.  For my redesign, I put together a hybrid of hopscotch and sudoku called Hopsudoku to try and add a puzzle element and make the game more attractive to an adult audience.  One thing I underestimated was the physical component.  Hopping doesn't sound like a very strenuous activity but hopping for long enough during playtesting does get tiring!

Our second project was to write a list of at least 100 games we've played throughout our lives, listing at least three for each year we've been alive since we were five, and include comments about memorable parts of of each of their designs.  You can see my list here.  I did my best to avoid overusing sequels as long as I could, but had to break down and do so to fill in some problem years here and there.  It was a very interesting exercise to go back and try and remember what stuck out the most for me over my gaming career, it might be fun to go back to it again at some point and try to make the list as exhaustive as possible and see how high a number I can get.

ETC Semester Project - Spring Entertainment

So with the first semester and BVW behind me, I'm now moving forward as a member of the Spring Entertainment project team here at the Entertainment Technology Center.  Spring Entertainment is a client project working for Seven Springs Mountain Resort.  Our goal is to create an iPhone game that advertises the variety of experiences available to guests at the resort.  You can read more about the project and follow our progress in our weekly newsletters available here.

On Stage at the Fall 2011 BVW Show!

Great news!  Two of my teams' worlds from this semester's Building Virtual Worlds class were selected to be featured in the Fall 2011 BVW Show!  Each year BVW students are allowed to submit worlds from any round to the BVW Jury for review, who then assemble a show from the best worlds to be put on stage in front of a live audience.  This semester over 90 worlds were created, 60 were submitted to the jury, and fourteen of those were selected to be in the show!  Here are clips from the show of the two worlds I was a part of.  I was a performer on stage in both of them.

Mouse <3 Mouse (yes, that's me in the mouse costume)


Electro Techno Corps (playing the role of Captain Electro in the middle)


The entire show was a huge success!  You can watch the whole thing online here:
mms://wetc-tv.etc.cmu.edu/stream/2011_semester_3/class/bvw/bvw-pgh_2011-fall-show.wmv

This marks the end of my first semester at the Entertainment Technology Center!  Next up is a short winter break, during which I might find a little time to get back to work on Shining Force PC!  After that the next semester starts in mid January which will be a whole new adventure working on a full semester long project as opposed to the short 2-3 week rapid prototyping rounds of BVW.  I have to say that this semester has been the most exciting three months I can remember in forever!  I've made so many great friends and had a wonderful time creating amazing things together with them!  I only hope that the rest of my time here at the ETC will be this rewarding!

Building Virtual Worlds - Round 5 - Electro Techno Corps

The theme of Round 5 of Building Virtual Worlds is Its Showtime!  Students are given one month and are tasked with building a world that is big on showmanship and spectacle with the goal of being featured in the Building Virtual Worlds Show at the end of the semester.  Unlike previous rounds, students are permitted to form their own teams and pitch a concept to the professors or take the luck of the draw and be assigned to a random team like in previous rounds.  I was placed on a random team and the world we came up with was a giant robot themed game called Electro Techno Corps (a pun on ETC.)  The world is in the vein of saturday morning cartoons and the Mighty Morphin Power Rangers. Three performers share two Wiimotes and two nunchucks to pilot a giant robot against a mad scientist whose giant creations run amok in the city.  The current video only has the game aspect of the world on display, if and when a version that also includes the live performers becomes available I will update this post. Update: a version with live performers is now online, check it out in this post!



Despite the large time frame, one of the major challenges of the round is time management and proper scoping of the project.  Many teams reached too far and ended up having to scale way back or start over completely around the halfway point in the round.  My team just barely managed to finish our world based on our original plan, which was way too close for comfort.  I wish we would have cut one of the events early on and spent more time on polish, playtesting, and fine tuning, but thankfully everything worked out in the end.

One of the more interesting aspects of the project was using CityEngine to model the city rather than doing it by hand.  Our texture artist, Anisha Deshmane, spent a lot of time in undergrad working with CityEngine and we were able to get the city modeled, exported to 3DSMax, trimmed down, and imported into Unity in under 2 days!  It saved us a lot of time and effort and looked great in game, which let us spend more time and effort on other aspects of the project.

Building Virtual Worlds - Round 4 - Mouse Heart Mouse

Building Virtual Worlds Round 4 is the Storytelling round.  Groups are given three weeks to build a world that lasts 3 to 5 minutes that tells a complete story.  Students have two days to come up with and pitch two story ideas to the professors and the class and receive feedback from them.  They then choose one of these ideas to build storyboards for, which are presented at the end of the first week.  Over the next two weeks students build the world laid out in the storyboards.

My group’s story told the tale of a mouse who meets a computer mouse atop a desk in a messy dorm room while scavenging for food.  The two fall in love at first sight, but are separated when the owner of the room returns and sits down at his desk and reaches for his computer mouse but grabs the furry mouse instead.  Shocked, he flings the mouse away and runs from the room screaming.  Our hero must find a way back to the top of the desk to reunite with his love, and then the two must find a way to escape the room and enjoy their freedom and their new life together.



My team this round worked exceptionally well together!  We all really liked the idea we came up with and that lead to very good buy in from all the members of the team.  Everyone made strong creative contributions to the project and we all worked very hard to make Mouse <3 Mouse a big success!  One of the things that I believe greatly contributed to that success was our choice of platform, the Nintendo Wiimote.  Since this was a small, simple piece of hardware, we were free to use it at our desks and we could playtest and iterate constantly unlike the rounds where I worked with the Kinect.  Since the Kinects and televisions were in very short supply, teams had to schedule limited time slots to playtest and it was harder to get a feel on how the world plays and make adjustments when working with that platform.  The freedom to playtest regularly on the Wiimote made it easier to fine tune the controls and left more time to polish the room and make it as lively and interactive as possible.

Building Virtual Worlds - Round 2 - The Pharaoh's Messenger

Building Virtual Worlds Round 2 is the Naive Guest round, the assignment is for students to build an experience for a user who knows nothing about their world.  At finals for the round a naive guest is given the controls and the team who built the world is permitted at most one verbal instruction to help the guest complete the world, all other instruction must be given from within the game.

My team's world, The Pharaoh's Messenger, used the Head Mounted Display platform as its interface.  The HMD is a set of goggles the guest wears coupled with up to four positional and rotational sensors that can be used any way a team wants.  Our team used two, one on the HMD goggles to update the guest's view of the world based on what direction they were looking and another attached to a physical ship's wheel prop that the team assembled that used rotation data to steer the ship.  The wheel was also meant to communicate as clearly and directly as possible to the guest what the interface was and how to use it.  Instructions in the introduction were given using pictures only since we did not want to assume the guest necessarily even knew English.



The key to the round was playtesting, the challenge being that once someone playtests, they're no longer naive about the world and further input about their experience on successive runs becomes less useful.  For instance, my initial implementation of the steering interface was actually rather counter intuitive, but since I had been testing so much from my workstation using the mouse and not as much on the HMD hardware in the lab I underestimated how off the interface actually felt.  Once I got some testers in front of the game that were not on my team and saw how much trouble they had steering, I scrapped the original implementation and started over and ended up with a much more natural feel for the steering.  Further testers we brought in were also very helpful in redoing the visual aesthetic based on what they thought they saw in the world rather than the reality of what we put there, which is how the game ended up being set in Egypt on the Nile river rather than on a generic river on a grassy plain.  Even the title ended up being a helpful tool to convey a ton of important information: who the player is, the time and place, and what their objective is.

Round 2 was an interesting learning experience for a lot of reasons, one of which was from working on a larger team of 5 instead of the usual 4.  I did a lot of things with the project to enable and encourage the other team members to contribute to the scene file in Unity, which had its pros and cons.  It got the team more involved in working with the project and Unity itself which was good for morale and educational for the people on the team who had not done a lot of hands on work yet with Unity.  Myself, our texture artist Sean, and our sound designer Ricardo could often all be working in the scene at once, but as Unity scene files are binary, not text, changes cannot be merged, only accepted or discarded.  We lost some balance and tuning tweaks at once point and old bugs crept back in that I thought I had fixed.  I had gotten into the habit of usually discarding my changes to the scene instead of committing them since I often assumed Sean was making level layout changes and that his changes would involve more work to reproduce than mine.  Better communication about who was working in the scene file at any given time would have made that process go a lot smoother.

Building Virtual Worlds - Round 1 - The Shaft

So I finally have a free moment to start sharing some of the fruits of my labors over the past several weeks of my first semester here at CMU's Entertainment Technology Center!  The central course of the first semester is Building Virtual Worlds, a rapid prototyping class where students are divided teams of 4 or 5 and are tasked with building interactive experiences over two weeks.  It's all about teamwork!  We all had one week to do a solo project to get the hang of the tools we would be using, C# and Unity3D in my case, and then we were off!

My round one project was The Shaft, an adventure game where the player wakes up at the bottom of a shaft in the earth in the middle of a heavy rainstorm and has to find his way out while avoiding hazards like drowning in rising waters, bats, and rockslides.  It used the Microsoft Kinect as it's player interface with a simple gesture system I built, which came together quite smoothly thanks to the Kinect wrapper for Unity written by our upperclassmen!



C# took a little getting used to but thankfully it is close enough to C++ that I was able to adjust quickly.  I still feel like I am being lazy letting the system do garbage collection for me, but I'll get over it!  Unity3D itself is also very nice, and uses a lot of the same paradigms I use in SFPC, which also helped make for a quick learning curve.

Exciting Changes Ahead!

I have some great news to share!  I've been accepted to Carnegie Mellon University's Entertainment Technology Center graduate program!  I'll be working very hard towards earning a Master of Entertainment Technology degree over the next two years.  First semester begins tomorrow!  It's very exciting.  I have several friends who are graduates from this program who all speak very highly of it, and it was their tales that inspired me to reach for the stars and apply.

What does this mean going forward?  Odds are, you'll be seeing a lot fewer SFPC updates, but with any luck and a little free time (I hear that's in very short supply for ETC students!) you'll see some new posts on some much bigger and much different projects that I'll be working on in the months ahead.

For those of you who have been eagerly following my progress on SFPC, please know that the project remains very important to me and I intend to work on it more in the future when I have the time.  All my hard work on SFPC was what earned me this opportunity, and I don't intend to abandon it.  Ultimately this is a very good thing for the project.  I'll be making lots of new friends I could possibly recruit to help out with graphics, sound, or code.  My own skills will undoubtedly grow far greater and I'll be much better equipped to make SFPC even better.

And with that, I'm off to have my world turned upside down and inside out, and have my mind blown.  Wish me luck!

SFPC - August 2011 Update

So, it's been a while since I've done any updates on SFPC.  I'll admit, things definitely slowed down for a while, what can I say, I needed a break (or two)!  Despite the lack of posts, I have gotten a lot of work done over the past few months, though the bulk of it was not really video or blog post worthy.  This release represents the sum of the year's changes so far, which includes lots of bug fixes, a major revamp of the movement code for performance reasons, and some new editor features and engine enhancements. 

There's no new gameplay map to try, hence the lack of a video.  The main draw of this release is the enhanced editor, which includes several features which should be a big deal to anyone interested in making maps.  Press the Home key to toggle between Play and Edit modes.

- The engine now supports variably sized maps, anywhere from a minimum of 28x20 tiles (two screens wide by two screens tall) to a max of 255x255.

- The editor now supports a sort of command console, think of the ~ menu from shooters like Quake.  From within the editor, press F12 to open the console script.  It opens a regular script window in Notepad.  Enter whatever script commands you like, save the file, then press F9 to run the script.  It is meant for one-and-done commands, and the file is wiped each time it gets loaded.  Two new script commands have been added specifically for use with the console:

• TileFill tilenum layer x1 y1 x2 y2  -  Does a fill on the active map from x1, y1 to x2, y2 of the specified tile on the chosen layer.  Must be a valid, in bounds rectangle, or nothing will happen.  The editor UI now shows the corresponding integer version of the active tile for use with this command.  Layers are background = 0, overlay = 1, foreground = 2.  Great to make a large space, or even the entire map, get set to a specific tile, for instance an indoor map might use a pure black tile on the edges instead of a grass tile.

• CreateNewMap "mapname" width height  - Creates a new folder structure in the /maps/ folder for the specified map name, as well as blank default map and event scripts.  The editor does not load the new map immediately, the choice to save unfinished work (press F5 to save) and switching to the new map with either F1 to load maps or the Warp command in the console script is left up to the user.

- The editor itself now has a more robust tile editing system:

• The editing cursor now supports brush sizes.  Increase or decrease the size of the brush with the Page Up and Page Down keys, from 1x1 up to 5x5.  Changing the brush size fills the brush with the active tile.

• The editing cursor now also shows the contents of the current brush at half transparency over top of where it is pointing.

• The C key is still used to copy tiles, and will now copy the contents of the selected area to the entire brush.

• Any time the user changes layers or modes within the editor, the contents of the brush is erased and the size is set back to 1x1. 

For those curious enough to give the new editor a try, you can download it here.  The maps from the previous demos are included, you can open them up and tinker with them if you like.  There is also a scripting cheat sheet in the readme, along with the list of controls.  You may want to associate .sfs files with Notepad for ease of use, just double click one, tell it to open with Notepad, and leave use this by default checked.  You may also want to refer back to some of my older posts and videos for a refresher on how to use the editor.

Please feel free to email me if you have any questions on making maps or scripting or to let me know about bugs, or you can post in the comments below.  If anyone makes a map and would like to share, let me know, I'd love to see them!

2010 Year in Review

It's hard to believe it's already been a year since I started sharing my progress on SFPC here!  In that time I've gone from what amounted to a simple map viewer and editor that could show a few text windows to something that is really starting to resemble a game, as can be seen below!



Want to try the demo for yourself?  Download it here.

Over the past 11 months, new additions to the engine have included:

• Music and sound effects via the Audiere sound library
• A custom scripting language used both to control game events and logic and construct game assets such as characters and equipment
• A turn-based strategy RPG combat system with basic enemy AI
• Animated battle cutscenes that show the results of each engagement playing out on the battlefield
• A more robust system of windows and menus that tie the game together
• Some slides (.pdf) discussing some of these features in more detail are available here.

I've come a long way as a programmer as well.  The hours and hours of work on SFPC alone have provided great practice, but I've also been reading some great books such as Scott Meyers' Effective C++.  I've been taking my time reading it, applying what I learn to polish and refine SFPC to make sure the lessons stick.  I've also learned a lot from my recent experiences in trying to get a job as a programmer in the games industry.  I'm not there yet, but I'm still trying, learning more and more as I go, and it's only a matter of time now before I finally get my big break.  I just have to keep reading, keep programming, and good things are bound to happen!

SFPC - December Combat Test Video #6

This time around I've got two new features up and running: attack range based on a character's equipped weapon, and target selection and confirmation.  Weapon graphics ended up getting put on the back burner for a bit, but they're still in the works.

I didn't work much on new features for SFPC in November.  I've been reading some good books and sharpening my general C++ skills, so I went through a lot of my older code and did some clean up and general maintenance to apply what I've learned.  Still a lot of code left that could stand to be polished and tweaked, but I decided to take a break from all that and do some new features and a video.

SFPC Items Update

Click here to view on YouTube to go fullscreen and HD



Two updates in one day!  Here we have the Items update, featuring scripted items and the new equipping windows.  Also of note is the new colored text system, which simply *1works like this.*0  The *1 would set the text color to orange, then the *0 would set it back to white.

The next update will probably be another combat one, in which I actually do what I set out to do when I took this detour, which is have weapon graphics display in combat.  Ranged attacks should also be pretty easy to implement now as well.

SFPC Editor Demo Video

Part 1:  Click here to view on YouTube to go fullscreen and HD



Part 2: Click here to view on YouTube to go fullscreen and HD



These are long overdue! Here you can see how I use the SFPC editor to create maps and script events. I'd like to believe that this system is simple enough that a novice could dive right in and be making maps pretty quickly given a little time, documentation, and encouragement. Part of the building up of that "documentation" is videos like this.

SFPC - August Combat Test Video #5

This week the big new feature is combat animations!  They're still pretty basic, no weapon graphics yet, I need to improve the item code a lot first before that happens, but aside from all the punching going on, things look pretty good! 

SFPC - August Combat Test Video #4

Another productive weekend!  Lots of bug fixing, under the hood changes, and asset ripping, but a handful of new stuff as well, hence the video.  Scrolling text may look simple to the untrained eye, a little thing we all take for granted, but it took a good bit of work to get it looking right and behaving alongside everything else.  Battle movement has also received a tune up, characters can move through (but not stop in) squares occupied by allies, and enemy squares are excluded from movement range calculations.