I had 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 architectural students the professional skills and practices they will need to succeed in the real world.

The project lasted for two terms, around 6 months.  For the first term, we had a large development team of around 20 or so, and for the second, our team shrank to about 6 or so.  We collaborated with architectural students, who were able to give us very valuable information and an informed viewpoint that helped us tailor the project to the field of architecture.

–Systems Design Breakdown —

The core system went through two iterations.  The first incarnation of the system had largely been worked out by my professor and project lead when I joined the project, but I was involved in further developing and building out that system.  Later down the road, we decided that we needed to change the way our progression system worked in order to make scenario creation easier and faster.

The basic structure of the game involves players working their way through a number of different scenarios, talking with clients and responding to different situations that arise during a contract.  Each decision players make affects their scores in seven different categories, Finance, Ethics, Environment, Communication, Public Relations, Time Management, and Office Relations.  As players make decisions, they are constantly being evaluated based on these categories, while also trying to keep the client happy. This creates an interesting dynamic where these different factors are in opposition to the wishes of the client.  Players must balance keeping the client happy, while considering the brander impact of their decisions.

Scene Progression

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.

It broke down like this:

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

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

– 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.

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.  Now, any choice can lead players to any in the scenario.  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.  To simulate this, we implemented a minigame in which players must interact, or choose to ignore, their co-workers.

There are four different NPCs that approach the player’s desk.  depending on which pose they appear in, they could offer the player advice, ask for help, or they could want to share the latest gossip. Players can then choose to ignore them or talk with them, but doing so will have an effect on the player’s time management and office politics.  The player has to balance being a good coworker without wasting too much time on idle gossip.

Scenario Creation

For our second term of development, we had a student from screenwriting bought on to assist us with writing scenarios, but during the early days, the other grad student, David and I were very involved with the scenario creation process.  The architecture students provided us with situations they came up with that would provide interesting, challenging dilemmas that an architect might face.  It was then our job to take these concepts and make them workable in the game.  We had to go through and assign point values for the categories that each choice effected, as well as write dialogue that would make each choice sound viable to players.  One big takeaway I found was that it can be pretty challenging to create choices that you know are wrong, without making them sound wrong to players.

— Development —

In addition to acting as a systems designer, I was also the head of Unity development for the project.  It was my job to ensure that assets and code all made their way into the engine, and ultimately my responsibility to get all the pieces working together.  I did a lot of coding for the project, and was able to learn a few techniques that I had never used before.  I decided that our scenarios should be saved and read in as xml files, which made then easily editable.  I hadn’t worked with reading and writing xml files in the past, so it was a great opportunity to learn.

Taking code that had been written by several other people and getting it all to function together proved time consuming, and if I could do the project over, I would have handled some elements differently, but I think it was a success overall.