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.

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.

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

Feedback–

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.

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.

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.