Choosing the player’s perspective in a game is a crucial decision. Not only does it affect how players perceive the gameplay environment, it also creates expectations on how the game should be played. For instance, if you begin the game looking at the back of a car, it’s reasonable to expect that you will be driving the car.

In the game we’re developing, we’re working with a number of assumptions:

1. 1. The player can select and control more than one character in a serial format (one at a time).
2. 2. The environment is deformable and can be shaped by the player.
3. 3. The default control scheme is “click-to-move.”

For these reasons, we had decided that an isometric perspective would best suit our needs. Games with an isometric perspective provide an omnipotent feel (going all the way back to Populous) that we thought would convey the player’s role in our game.

That was the theory anyway.

(more…)

Some years ago I interviewed for a job as an artificial intelligence programmer working on the latest title in a well-known RPG franchise.  During my tour of the studio, the producer showed me the latest build of the game.  The engine was fairly far along and there was at least some content - a world with buildings, liberally populated with character models.  But lacking any AI, the characters simply stood around, unanimated, like so many statues.  It would have been my job to add the AI to drive animations on the models, and then game systems governing their interactions with the players.  In the end, I chose to go with a different company, mainly for real-life practical reasons.  But the image of those static characters, and the opportunity to breathe life into that frozen tableau, was very tempting.  It was difficult to turn down that job!  (They also had crab cakes in the cafeteria at lunch… very difficult to turn down that job.)

That particular road-not-taken was an example of what I’ll call “gameplay integration”.  Gameplay integration involves taking different pieces contributed from different areas of the team - art, design, and perhaps other engineers - and putting them together to create gameplay.  These programming tasks typically include a generous dose of artifical intelligence work, plus input processing/player control and often some user interface work.  It’s essentially where the end result, the player experience, is born.  For me, it is one of the most enjoyable aspects of game programming.  Our Thinglefin project has ample opportunity for this kind of work, and a recent task made me recognize two distinct pleasures that it can bring.

(more…)

We have a press release going out tomorrow. Its mostly boring stuff concerning our financing, but it does mention a couple of newsbytes on the game we’re developing. If you’re reading this blog, I imagine you’re a hip netizen, searching for the next juicy gamedev morsel. Or more likely, you’re Ryan’s Mom. In any case,  I thought I’d scoop our own press release, and spill the little bit of game-specific information it contains.

(more…)

Like any small company, we each wear a lot of hats at Thinglefin. For instance,  Jeremy is de facto IT guy and web site administrator in addition to his primary role as high arcanist/coder.  That seems to make sense to most people, and no one seems to question that particular combination.

But often, when discussing my own contributions to Thinglefin, I find that people are surprised that I’m both the business guy and game designer guy. Now admittedly I have no prior experience running a company and for the people that know me, thats likely the root of their surprise. However, I get the same reaction from people I’ve only just met. Its like the two roles don’t fit together in the interdisciplinary cosmology; they’re on opposite poles from each other.

Of course I understand how, on the surface, game design and business planning seem unrelated at best, and possibly antithetical at worst. However, when viewed in a certain light, I actually find that the two have a lot in common.

Good game design communicates a vision of how a game will work. It provides a road map that enables a team of developers to craft a finished product, and just as importantly, it provides course correction when the result doesn’t meet expectations.

Similarly, good business planning communicates a vision of how a company will work. It provides a road map that enables an organization to reach profitability, and just as importantly, it provides course correction when the unexpected occurs.

Both must function with established limits (hardware requirements and market size), occasionally byzantine regulation (ESRB and the IRS), and demanding audiences (beta testers and the board of directors).

And the truly outstanding ones? Well, they’re able to define whole new categories.