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.