Game Design: SALARYMAN

A robust turnkey video game that will take you to the granular level of intuitve simulation where you as the advocate must mitigate risk and excel in a team-centric environment featuring real-time interactivity with fully-modelled NPCs who are unskilled and unaware of it.

TenNapel on Game Design

An interview with Doug TenNapel, who designed The Neverhood, Skullmonkeys, Earthworm Jim and the ridiculously good comic book Creature Tech. He makes some good points, if nothing mind-blowing, and he's efinitely been on the inside of plenty of games, good and bad.

I love him, though he's also possibly crazy.

(sent to me by Birru)

Sprezzatura Productions: News

Also, Sprezzatura might be moving to a new phase as well, joining forces with a compatriot. We'll see, though.

ExRay Records: News

So, this is just a note to say that ExRay Records might be going from a sort of quasi-boutique label to a quasi-"real" label, with the help of Lujo Records. I have worked with Lujo listening to demo submissions for some time now and it's been a good time, but now Erik has proposed that I start my own label.

I have to admit that, partially, I am not sure that starting a record label now isn't like chaining oneself to the limb of some kind of prehistoric animal, beset by its final, dying flails. But, heck, it might be fun. Any ideas?

Code Progress

I am posting to drop like a bomb some of the source code I have been working on for the Enginue project. People other than coders will not find this release to be of any interest, but the basic skeleton of a game engine is coming together. The posted source code includes the seeds of a game engine, a simple console based lua interpreter, and the base class from which all Task objects (the basis of activity in Enginue) will derive, including a simple task Simple_Lua_Task with a lua, object oriented interface allowing for the instantiation and automatic garbage collection of C++ Task objects using Lua's garbage collector.

Things which still need to be done/immediate areas of progress:

1) Documentation

2) Engine/Thread integration. I should consider this carefully since I expect to eventually convert the console based console into a virtual/graphical console which can be accessed from inside a game session. I may need to think about that now.

3) Further refinements of the interface traditions so that they remain manageable for more complex tasks.

I think, generally, that I will work on enough Task types for a Tile based game engine first and then turn my attention to the more complicated problem of physics based games with ODE.

I am growing to appreciate C++ as I work more and more with it, but I do have the following gripes: the first is that there is no ANSI standardized way of dealing with console input in any kind of sophisticated way. This leaves me unable to write a nice interpreter without running the risk of endangering platform independence. This is a good reason to move to an internal console, despite the added complexity involved.

I still feel that C++ just misses the mark with respect to several programming techniques. In addition to being extremely verbose, C++ offers the possibility of higher level programming without most of the power. Sure, there are methods which let you map functions onto containers, but without anonymous functions, they are not extremely useful. There are other things like this, where you feel as though you are almost, but not quite, able to make use of a high level idiom. These annoyances remind me of my desire to make the lua wrapper thick around simple c++ code, so that I can make use of the abstractions that Lua gives to the user. For the remainder of the code base, C++ is turning out to be tremendously more convenient than C might have been for what I am hoping will be similar performance.

The code as it is can be found here. Lua is included along with a copy of its license. You need scons to use my automatic building process. If you have it installed, then simply navigate to the enginue directory and type scons. My code is published under the GPL for now (a copy of which is included in the source directory) and the other packaged softwares (lua, ode) are licensed under their native licenses. If anyone with skillz is reading this, let me know what you think.

.plan

The engine has a clever name: Enginue (pronounced ingenue). Its using an extended Lua interpreter, which we might even call Luanne just to keep with the feminine naming conventions. I would like Lua to be a rather thick wrapper on the very thin, simple C ++ code. A typical session would go:

[Launch Enginue]
* Enginue executes autoexec.lua
* This configures the screen, starts up the naked engine, registers a splash screen task

at this point autoexec would 1) pass control to another script which sets up other tasks or 2) call a function called enginue.console which will give the user a command line console. The user should be able to do things like:

>> print(engineu.ls_section_types());
['ODE','classic']
>> s = enginue.section('ODE');
>> s = enginue.activate_section(s);

These two lines should create a new section and make it the active section. A section corresponds to a single continuous area in blue_arizona (or any other game). A section should be of extensible type, that is, we should be able to support many different kinds of sections. Tile based sections, with tile based collision detection, and ODE based sections with ODE based collition detection, should be the first supported. We should be able to do things like:

>> polygon = { xpts = [0 0 1 1], ypts = [0 1 1 0], visible=true, type=SOLID };
>> id = s:add_polygon(polygon);

And a nice, blue, solid polygon should appear in at the position which you set.

The interpreter should expose placement of objects, their types, how they interact with the physics engine, how they react when collided with (which I think will be decided via Lua scripts)
the placement of the player, what abilities the player has (powerups), perhaps whether the little man is in the ship or not, if we decide to go that way. You should also be able to do something like:

>> callback = { toid = id; section = s; function call() { p = s:rm_polygon(id) } }
>> polygon2 = { xpts = [2 2 3 3], ypts = [2 3 3 2], visible=true, type=TRIGGER, callback = callback };
>> id2 = s:add_polygon(polygon2);

So that triggers, which are handled by the engine, be written in lua and registered with the engine. This way, its even possible we could write C++/C scripting functions, compile them, link them at runtime with Lua and do something like:

>> fastscripts = loadlib("fastscripts","lua_open_fastscripts")
>> polygon2 = { xpts = [2 2 3 3], ypts = [2 3 3 2], visible=true, type=TRIGGER, callback = fastscripts.cpp_callback };

Thats enough for now!

One Billion Mazes

So you can find a copy of the latest set of source code for the engine here.

C++ is a pain, but I suspect its just because higher level languages have left me spoiled and lazy. I am strongly resisting the urge to abandon C++ for something more interesting, like Common Lisp.

But I won't.

In other news, there is this site, which features, as the URL implies, exactly one billion mazes. Stripped of its outer skin, all video games are essentially mazes of one kind or another. BlueArizona, as an explorating game, makes its maze nature particularly evident.

Mazes are strange things, in their purely abstract form. The user proceeds purely algorithmically, since no strategy beyond exhaustive search of paths presents itself for their solution, and this leads in many cases to a series of dead ends. Without a story or a setting, a dead end is a penalty, and a minor irritant, though perhaps the very imaginative child might supply the experience with a narrative.

Video games, especially the really good explorating games, make dead ends the reward, while the ultimate end point of the maze is a foregone conclusion. In Castlevania: Symphony of the Night there are countless such dead ends, useless little rooms in which we are treated to nothing but the life cycle of nesting birds or some similar little detail. Dead ends also become fertile places to plant power ups, useless or superfluous items, bits and pieces of the story.

BlueArizona should exploit its maze nature in this way.

"Progress" on the Arthur Harrison Documentary

Those of you who know me, know that for the past three or so years, I have been working on a documentary featuring Mr. Arthur Harrison. Harrison is an electronic instrument designer and builder, specializing in theremins, which he also plays quite well, including work with my band The Cassettes (you can read a sort of review about him here). Well, after shooting somewhere in the neighborhood of 45 hours of footage, you might say that I was a bit burnt out. I enlisted several compatriots to help out, but perhaps without the benefits of financial remuneration, those enlisted were somewhat less than active after a short period of time (this should not sully the names of such people as Ms. Abby Moser, who was quite important to the production process). As such, the gears of the post-production process ground to an effective halt.

No more.

I have recently transferred 6 hours of footage filmed during the snowed-in weekend of February 2003 from miniDV to VHS and I intend to begin "logging" and "capturing" this footage over the next week or so. Afterwards, I shall do the same with the rest of the footage I have, as well as attempting to reclaim the footage in the possession of other individuals. Next comes the editing process.

If anyone would like to assist me in this time consuming process, please write to stephen [dot] guidry [at] gmail [dot] com

[Sprezzatura]

Blue Arizona, The Night Land and Robots

As our imaginary readership no doubt knows, we here at the Exrayfactory, specifically under the auspices of the probably superfluous designation Bremsstrahlung Games, have been working on several projects, the one furthest along being code named BlueArizona. BlueArizona tells (is that really the right verb for a video game?) the story of an elderly Tinkerer who, at the behest of some subtle influences, constructs a dimensional transportation device and ends up in a far away land, amongst the ruins of an ancient civilization. His little sphere-shaped craft rolls and bounces around on a force field, the The Tinkerer must explore what will hopefully be a large and well developed world, not only for clues as to where he is and what happened there, but ultimately how to get home.

Objectively speaking, I would say we are approximately 10-20% finished with the task of making this game, despite having passed around now a few amusing demos which I "rapidly prototyped" up in Python.

Since I am responsible for the programming, I have the following plan: I will follow, with some deviations and improvisations, this set of articles by Richard Fine on the construction of a game engine in C++. This course of action is motivated by several factors, the first of which is that I do not really know how to write a game engine, my primary experience being in data analysis with some experience in algorithms. Other factors include speed and a clear distinction between the engine and the scripting system, two things which Python does not provide. To that end, I will be using the very nice Lua Programming Language for our scripting system. In preparation for using Lua, I converted the scripting language in GNU Robots (Guile, a Scheme), an interesting little game in which the player programs a robot to navigate a virtual world, to Lua. The results of this effort can be found here. The source code is released under the GPL, and the included binary is compiled there against a system which has the Lua libraries where an Ubuntu would put them. I am also experimenting with SCons, a build system which we might eventually use to build the whole engine. The source is not extremely complicated and the enterprising young Linux or Windows user might be able to get it to compile. Finally, the C++ engine described in the above articles will be able to serve duty in any number of future Exrayfactory games with some additions and removals, hopefully forming a useful code base. The Night Land in particular should benefit, and if we ever want to take that frightening step into 3d, we will be able to use it then as well.

The other pressing issue about is the actual game design, story flow, elements of play etc etc, which I am leaving hopefully in the hands of my partners in this venture.

I welcome comments about Lua, Scheme, video game engines in general or even Lua Robots.

PS - If I appear to be affecting a peculiar diction its because I have been listening to The Time Machine, By H.G. Wells. I think we might want to read this book, since it has many things in common with the basic story of BlueArizona. What does everyone think?

[Bremsstrahlung]

if only I could do it all over again

I finished Shadow of Destiny for the PS2 the other night. Published by Konami, it was a first generation PS2 title directed by Junko Kayama. Her previous credits include the lead scenario writer for the PSX Suikoden games.

The premise is simple yet maddeningly complex: the player must travel through time to prevent his own death. There is a catch, however: you can't choose whatever time you want to go back to. Instead, the time periods which are only made available to you based on their relevance to your current predicament. What makes this connection "relevant" or not often seems arbitrary, though as the plot unfolds the connections between time periods become more apparent.

The game is set in the German village of Lebensbaum, any time from modern day to the 14th century. The plot is winding and incestuous, often relying on circular logic and narrative sleight of hand. As outlandish as the plot becomes, the characters are, with only one real exception, down to earth, ordinary people who one way or another wind up wrapped up in a clusterfuck of time travel. There are small moments of family drama, personal tragedies, and casual slices of life. Though the voice acting is occasionally awkward and hammy, the characters are well articulated and nuanced, if not always entirely natural. Because of this, the game always feels grounded and real even when the plot becomes seemingly incomprehensible.

The game's presentation is really breathtaking. Lebensbaum, as it's depicted in past and present, has got to be one of the most meticulously arranged and detailed environment I've ever encountered in a videogame. There's nothing too impressive going on technically: polygon counts are low and special effects are sparse, though the framerate remains at a consistent 60 fps. However, the texturing and object placement are extremely detailed and varied, and the art direction is similarly focused. It's possible to play through the game many times and still miss minor details in the game's environments. With this aesthetic sensibility firmly in place, it's without a doubt one of the most gorgeous looking video games I've ever played. Objects on screen are perfectly laid out as if the environments were designed with every possible viewing angle in mind.

The score is also hauntingly beautiful, evoking subtle moods ranging from placid summer afternoons to anxious, paranoid nights. Depending on where you are and what music is playing the game can be either invitingly beautiful or hauntingly surreal, and often both at once.

Because the game paints such a compelling portrait of individuals and settings, it makes the actual somewhat frustrating gameplay a little easier to bear. The game relies far too strongly on cutscenes to communicate its plot, so much so that some chapters consist almost entirely of watching cutscenes, and then making a brief set of (often blindingly obvious) decisions that alter your fate. Often between cutscenes the plot has made so many twists and turns and introduced so many new characters and settings that it's difficult to remember what you were supposed to be doing to began with. Other chapters are a little more pleasant, giving you a chance to explore the village and gather information if you like, and a few are even challenging and force you to do some lateral thinking.

The gameplay is in a standard adventure game style; the puzzles tend to be simple if a little obtruse, and every now and then you must fall back on trial and error techniques to figure out exactly what you need to do.

After finishing the game, I'm at a loss as to whether or not it's absolutely brilliant or completely retarded. This is the sort of game that lives and dies by its writing, and this game's plot makes Mullholand Drive's narrative seem logical and continuous. There are apparently something like 5 or 6 possible endings; I got the worst one. Perhaps I'll be able to understand the inner game's workings better if I figure out how to view the other endings.

I recommend playing it, however, because it's got a very strong and original concept that takes advantage of the unique strengths of the medium. In addition, it's probably one of the most beautiful games you'll play on this or any other platform.

Look for some kind of review/analysis in the March issue of Gamer's Quarter.

Inauguration

With little fanfare, The Exray Factory "blog" is given wings to fly, wheels to roll...what happens henceforth is left to the Fates.