GameNotGame

Non trivial Property Drawers in Unity

2013-12-02T22:39:00.000+01:00

Another programming related post... I promise I'll publish something nicer next time.
Also, because Google insist on making their products consistently worse, I am unable to upload pictures. This is going to be even drier than usual.

Recently, Unity added a new tool to its arsenal, in the form of Property Drawers. They allow specifying how to display your own types inside Unity's editor interface, when contained as a variable of a MonoBehaviour. Previously we were limited to specifying how to draw a whole component, which had its limitations in terms of reuse.

So, now that you know they exist, you might start looking around for examples... only to find the most trivial one repeated over and over again: a Property Drawer for a class with one simple variable. But you want to display an array, or an array of colours, or a visual angle selector (which is used in an example, but its code is curiously missing). Something actually useful when editing complex games in Unity.

So, I'll save you an hour of reading through documentation and debugging weird errors. Property Drawers are very easy to use when you know what to pay attention to.

Basic case: a class with a Sprite picker

Let's create a simple class LayeredElement.cs, to organize Sprites.

LayeredElement.cs:

    [Serializable]
    public class LayeredElement {
        /// <summary>
        /// Order in which this element is painted,
        /// 0 being the background.
        /// </summary>
        public int layer;
        public int Layer { get { return this.layer; } }
    }

    [Serializable]
    public class NonConfigurablePart : LayeredElement {
        public Sprite sprite;
        public Sprite Sprite { get { return sprite; } }
    }

To display NonConfigurablePart we need to expose the layer and sprite variables. Currently I don't know how to display a texture/sprite selector using EditorGUI, so I'll use a simple selector and display the sprite independently.

NonConfigurablePartDrawer.cs:

    using UnityEditor;
    using UnityEngine;

    [CustomPropertyDrawer( typeof( NonConfigurablePart ) )]
    public class NonConfigurablePartDrawer : PropertyDrawer {
        // Default Unity line height
        private int textHeight = 16;
        // All sprites wiil take the same area.
        private int spriteDim = 60;

        public override void OnGUI(Rect position, SerializedProperty property, GUIContent label) {
            EditorGUI.BeginProperty( position, label, property );

            // Store the original indentation.
            // Since we are being drawn inside a component,
            // changing it could modify how later elements are displayed.
            int origIndent = EditorGUI.indentLevel;

            // Obtain the properties we are interested in. Accessing variables by name is error prone, so be careful.
            SerializedProperty layerProp = property.FindPropertyRelative( "layer" );
            SerializedProperty spriteProp = property.FindPropertyRelative( "sprite" );

            // Name of the variable this NonConfigurablePart has in the current MonoBehaviour.
            EditorGUI.LabelField( new Rect( position.xMin, position.yMin, position.width, textHeight ), label );

            // We don't use indentation, actually, so just get rid of it
            EditorGUI.indentLevel = 0;
            // Calculate the area to use for the layer field.
            // 130 is the number of pixels Unity usually leaves before showing variable setters.
            // Found via trial and error =)
            Rect layerRect = new Rect( 130, position.yMin, position.width - 130, textHeight );

            // Check if it was modified this frame, to avoid overwriting the property constantly
            EditorGUI.BeginChangeCheck();
            int layer = EditorGUI.IntField( layerRect, "Layer", layerProp.intValue );
            if (layer < 0) layer = 0;
            if (EditorGUI.EndChangeCheck()) {
                layerProp.intValue = layer;
            }

            // Calculate where to draw the selector (right below the layer field).
            Rect selectorRect = new Rect( layerRect.xMin, layerRect.yMax, position.width - 130, textHeight );
            // PropertyField updates the property automatically, so no need to BeginChangeCheck
            EditorGUI.PropertyField( selectorRect, spriteProp, new GUIContent( "" ), false );

            // Calculate where to draw the sprite
            Rect spriteRect = new Rect( 130, selectorRect.yMax + 5, spriteDim, spriteDim );
            this.DrawSprite( (Sprite)spriteProp.objectReferenceValue, spriteRect );

            // That's it. Some little house cleaning and leave.
            EditorGUI.indentLevel = origIndent;
            EditorGUI.EndProperty();
        }

        // Calculate height required by the component.
        // Notice the absence of position; we cannot rely on a controlled width...
        public override float GetPropertyHeight(SerializedProperty property, GUIContent label) {
            // Layer (and label), selector and the sprite itself.
            return this.textHeight * 2 + this.spriteDim + 5;
        }

        private void DrawSprite(Sprite sprite, Rect spriteRect) {
            if (sprite != null) {
                EditorGUI.DrawTextureTransparent( spriteRect, sprite.texture, ScaleMode.ScaleToFit );
            } else {
                // Draw a visibly unconfigured rectangle
                EditorGUI.DrawRect( spriteRect, Color.magenta );
            }
        }
    }

There is nothing extraordinarily complex here, but some very specific calls and behaviours.
Keep reading for something a little bit more complex.

Complex case: dynamic size with an array of sprites

Let's add another LayeredElement:

    [Serializable]
    public class ConfigurablePart : LayeredElement {
        /// <summary>
        /// Possible configurations of this part.
        /// </summary>
        public Sprite[] sprites = new Sprite[3];

        public Sprite GetSprite(int spriteIndex) {
            return sprites[spriteIndex];
        }
    }

Here we will need to expose layer and an array of sprites. For extra points, we will allow changing the array size from the editor.

ConfigurablePartDrawer.cs:

    using UnityEditor;
    using UnityEngine;

    [CustomPropertyDrawer( typeof( ConfigurablePart ) )]
    public class ConfigurablePartDrawer : PropertyDrawer {

        private int textHeight = 16;
        private int spriteDim = 60;

        public override void OnGUI(Rect position, SerializedProperty property, GUIContent label) {
            EditorGUI.BeginProperty( position, label, property );

            int origIndent = EditorGUI.indentLevel;

            EditorGUI.LabelField( new Rect( position.xMin, position.yMin, position.width, textHeight ), label );

            SerializedProperty layerProp = property.FindPropertyRelative( "layer" );
            SerializedProperty spritesProp = property.FindPropertyRelative( "sprites" );

            EditorGUI.indentLevel = 0;
            Rect layerRect = new Rect( 130, position.yMin, position.width - 130, textHeight );

            EditorGUI.BeginChangeCheck();
            int layer = EditorGUI.IntField( layerRect, "Layer", layerProp.intValue );
            if (layer < 0) layer = 0;
            if (EditorGUI.EndChangeCheck()) {
                layerProp.intValue = layer;
            }

            int arraySize = spritesProp.arraySize;

            layerRect = new Rect( 130, layerRect.yMax, position.width - 130, textHeight );

            // Array size. Beware of Unity's behaviour when resizing arrays.
            // If longer, the last element is repeated; if shorter, you lose the data.
            EditorGUI.BeginChangeCheck();
            int newSize = EditorGUI.IntField( layerRect, "Sprites", arraySize );
            if (newSize < 1) newSize = 1;
            if (EditorGUI.EndChangeCheck()) {
                spritesProp.arraySize = newSize;
                arraySize = newSize;
            }

            // Take a reference position for the sprite selectors, and draw below
            Rect selectorRect = layerRect;
            for (int i = 0; i < arraySize; ++i) {
                selectorRect = new Rect( selectorRect.xMin, selectorRect.yMax, position.width - 130, textHeight );
                // Accessing the array through serialized properties
                SerializedProperty spriteProp = spritesProp.GetArrayElementAtIndex( i );
                EditorGUI.PropertyField( selectorRect, spriteProp, new GUIContent( "" ), false );
            }

            // First reference
            int spriteColumn = 0;
            int spriteRow = 0;
            for (int i = 0; i < arraySize; ++i) {
                // Use the last selector as reference and increase columns and rows accordingly
                Rect spriteRect = new Rect( selectorRect.xMin + spriteColumn * (spriteDim + 5),
                                            selectorRect.yMax + 5 + spriteRow * (5 + spriteDim),
                                            spriteDim,
                                            spriteDim );

                this.DrawSprite( (Sprite)spritesProp.GetArrayElementAtIndex( i ).objectReferenceValue, spriteRect );

                ++spriteColumn;
                if (spriteColumn >= 3) {
                    spriteColumn = 0;
                    ++spriteRow;
                }
            }

            EditorGUI.indentLevel = origIndent;
            EditorGUI.EndProperty();
        }

        public override float GetPropertyHeight(SerializedProperty property, GUIContent label) {
            // layer + n * sprites + n / (sprites in a row) * sprite height
            int spriteCount = property.FindPropertyRelative( "sprites" ).arraySize;
            int spriteColumns = 1 + (spriteCount - 1)/ 3;
            return this.textHeight * 2 + this.textHeight * spriteCount + (this.spriteDim + 5) * spriteColumns;
        }

        private void DrawSprite(Sprite sprite, Rect spriteRect) {
            if (sprite != null) {
                EditorGUI.DrawTextureTransparent( spriteRect, sprite.texture, ScaleMode.ScaleToFit );
            } else {
                EditorGUI.DrawRect( spriteRect, Color.magenta );
            }
        }
    }

And that's it. We could add support for dynamic columns sizes, or made things prettier, but this is functional and educational enough.
I hope you'll use this new tool to make your artists' and designers' lives much better. Or even yours.

Limitations

Let's end stating the obvious limitations, and a strange issue I have with this demo.

First, since this draws independent properties, there is little you can do to configure how drawers for a common type behave. For example, there is no way I can configure all my NonConfigurablePropertyDrawers to display bigger sprites from Unity. Well, sure, there might be a way to hack some static information in there and expose it through the interface, but you'd display it every time- or hack a first-of-the-frame detector. But that's not usually required.

Second is the issue that Unity does not share the width of the Inspector area when calling GetPropertyHeight. With that simple data we could make menus more fluid, or change the way we display information on compressed configurations.

And the issue. If you try this demo (verified in Unity 3.1, with Texture2d instead of Sprite), you'll find that scrolling the inspector window results in the sprite drawers (and the magenta rectangles) appearing and dissappearing pretty much at random. I haven't found the cause, or whether that's caused by an error in my code, a bug in Unity, or some kind of render time limit I'm hitting. I've tested with just one rectangle, and since that failed, I'm guessing Unity does something it shouldn't.
Should you find a workaround, please let me know (comment here or tweet @elorahranma). I'll file a bug report one of these days, but being such a minor issue, I don't see it being fixed in the short term.

Implementing a Transition-based State Machine

2013-09-26T05:34:00.000+02:00

Warning: this is one of the code heavy posts I once warned about. Those allergic to discussions of programming topics or big listings of code (C# code; it's not that bad), keep walking. Or stay and become harder, better, faster, stronger...

In this article I will introduce a (probably not so) new approach to implementing State Machines, mostly for videogames. The reference is, as usual, Buckland's implementation in his Programming Game AI by Example book. His version of the state machine was and still is the de facto standard when coding small AIs or logical behaviours. Although new and improved systems exist, like Behaviour Trees, FSMs are still pervasive in the video game industry.

FSMs have been slightly improved through time, as languages and techniques developed, offering new possibilities, but the core remains pretty much unchanged. Here I will introduce one major revision to how SMs are implemented and, more important, used.

Basic introduction to the classic State Machine

In Buckland's book, State Machines are composed of several elements:

The State Machine itself, which contains

A reference to the machine's owner
The current state to execute
The global state to execute
The previous state, in case a behaviour requires going back to it

A base generic abstract class State<T>, with methods Enter, Update and Exit. Enter is called when the state becomes the current one, Exit when it stops being so. Update is called on every execution cycle (of the state machine, not necessarily of the game or entity).
A collection of singletons derived from State<T>, one for each behaviour T can display.
A messaging system which allows communication between entities. State<T> includes an abstract method to evaluate messages and treat them if appropriate.

Important details:

States are, curiously, stateless. That's why a reference to the owner is required: it must contain all the state information the machine needs.
It is considered in bad taste (but unfortunately common) to transition from outside the states themselves, but the state machine usually allows this through several hijacking methods.

Thus, each state is responsible for checking its possible transitions. State hijacking is supported via the global states, which check conditions outside the scope of low level ones. If used, global states usually become a state machine of their own, to support all the possible situations.

Problems with this State Machines

A list of the issues affecting state machines.

Verifying transitions

My biggest issue with the classic implementation is that it hides the transitions inside each state. To verify that a state machine is properly implemented you need to check each state's Enter, Update, Exit and TreatMessage methods, including the global states', and verify that the graph is properly represented. It doesn't take long before this approach becomes unwieldy.

This stems from a very simple fact regarding state machines: the number of transitions is always at least equal to the number of states, and usually increases non-linearly with it.

Code required

In well constructed state machines, the code each state is really about is usually small and clear. Unfortunately, given the requirements for each state to be a singleton and evaluate transitions, they end containing lots of boiler-plate code. The singleton itself can easily take more space than the actual state functionality.
Transitions introduce an extra series of ifs cluttering the Update method and rendering it hard to read. Add in the fact that if a state change is triggered, you must include an early return to avoid the rest of the Update to execute after the Exit method, and you've got yourself a pretty mess.

Having to evaluate messages doesn't help either, as it usually includes code to discard undesired messages (easily reduced by using messaging systems with configurable notifications), and treating all the accepted messages.

This means that the ratio of useful code (what the state does) to actual code in each state is way below half.

Global states

Global states are required to reduce the number of transition checks each state must do. If several states, under a common circumstance, transition to the same state, a global state can take care of checking and changing the state itself. This includes checking messages and the world state.

But the possible transitions can change over time, so global states also transition from one to another. Now, can we go to a previous global state? Can they be hijacked? Who controls their transitions? If kept unchecked, global transitions can become a monster themselves. Their only role was allowing reduction of transitions, but we now have more transitions to control in a level above all the actually relevant states.
Or, you can have just one global state which checks the current state and runs the required conditions for each. This gets ugly fast, too.

Messaging as hijacking mechanism

Eventhough state changes are expected to only happen from inside the state machine, by offering the possibility of checking messages the floodgates open. Now, if a new transition is required that no state checks, we can just send a message from the outside and add some code in the required state to react to the message. We might be upholding the letter of the law, as the transition is launched from inside a state, but its intent is broken: anyone is allowed to send a message and force a transition at any time. And your state machine suddenly looks like a very ellaborate goto-label with cheese all over it.

The ability to evaluate messages is useful beyond that, of course. Some messages only make sense if in a given state and produce reactions of their own, beyond transitions. But too often they become a simple hijacking system. As a matter of fact, Buckland's example of message treating in his book is just that: an entity waits for another one to send a specific message, and changes to the corresponding state.

No states reusing

Since a state contains its transition logic in itself, different machines are unable to reuse existing states, or would have a hard time doing so.

Poor support for hierarchical entities

This is a really bad one. If you have a hierarchy of entities controlled by state machines, you'd expect to reuse common, low level states for all of them. Unfortunately, given the fact that a state machine is defined as StateMachine<EntityType> and its states must match that type argument, that's usually not possible. The rules of covariance and contravariance play against us, most of the time. I'm currently working on a solution to this problem, which I'll try to publish later.

Transition Machine

Now, I'll explain my approach to solving some of these issues. Although my classes still use StateMachine as their name (that's the mathematical term, and I'll respect that), for this article I'll refer to my implementation as Transition Machine, to emphasize the difference.

The idea is to define states and transitions independently. The transition machine will store all the possible transitions, each containing the source and target state, and the condition required for the transition to be executed.

In other fields of computer science, it is common to define also Actions as part of the state machine. A transition may trigger an action, as well as entering, executing or terminating a state. In our case, we will be limiting the execution of actions to the Enter, Update and Exit methods of each state, so we don't need a particular class for that.

By defining transitions outside states we can now configure a transition machine in a much more straightforward way. The definition of transitions between states will be easily verified by checking it against the state diagram. Modifying and adding transitions is also easy to do, as it only requires changing the configuration of the transition machine. Worst case scenario, we will have to add new states and conditions, but these are now so simple that their construction is easy and less error prone than with the traditional approach.

So let's chech some code (all of it is available at the project's GitHub page). I've removed the XMLDoc, but the code is simple enough to be understandable without it. Refer to the repository if you need help.

The base state is no longer an abstract class, so we can instantiate and build a new one on the fly, provided the required functions are available:

    public class State<T> {

        public Action<T> OnEnter { get; protected set; }
        public Action<T> OnUpdate { get; protected set; }
        public Action<T> OnExit { get; protected set; }

        protected State() { }

        public static State<T> Build(Action<T> onEnter, Action<T> onUpdate, Action<T> onExit) {
          return new State<T>() {
            OnEnter = onEnter,
            OnUpdate = onUpdate,
            OnExit = onExit
          };
        }
    }

A new state can be created without requiring the whole singleton jadda-jadda, and can be kept as a static variable:

    static class EntityStates {

        #region Idle state

        private static State<Entity> idle = null;
        public static State<Entity> Idle {
            get {
                if (idle == null) {
                    idle = State<Entity>.Build(
                        null,
                        IdleUpdate,
                        null );
                }

                return idle;
            }
        }

        private static void IdleUpdate(Entity ett) {
            // Look for target
        }

        #endregion

        // ...
    }

And transitions are equally simple. Just a condition to check, a collection of states from which it can start or from which it cannot, a target state and a simple evaluation function:

    public class Transition<T> {

        public Func<bool> Condition { get; private set; }

        private State<T>[] fromStates;
        public IEnumerable<State<T>> FromStates {
            get {
                return fromStates;
            }
        }

        private State<T>[] exceptionStates;
        public IEnumerable<State<T>> ExceptionStates {
            get {
                return exceptionStates;
            }
        }

        public State<T> ToState { get; private set; }

        // ...

        public bool IsApplicable(State<T> currentState) {
            bool stateMatches = false;

            if (fromStates != null) {
                for (int i = 0; i < fromStates.Length; ++i) {
                    if (currentState == fromStates[i]) {
                        stateMatches = true;
                        break;
                    }
                }
            } else {
                stateMatches = true;

                if (exceptionStates.Length > 0) {
                    for (int i = 0; i < exceptionStates.Length; ++i) {
                        if (currentState == exceptionStates[i]) {
                            stateMatches = false;
                            break;
                        }
                    }
                }
            }

            return stateMatches && Condition();
        }

        // ...
    }

The State Machine code is similarly simple. It has the current and previous states, the list of transitions, a means to change states (via properties which do all the transition calls), and means to add transitions and check them.
You will notice that there is no global state or message managing here. Global states are unneeded because transitions can be defined for several source states at once. And messages should be treated by the machine's owner, who would update the information the transitions check as their conditions.

    public class StateMachine<T> {

        public T Owner { get; private set; }

        private State<T> prevState = null;

        public State<T> PrevState {
            get { return prevState; }
            private set {
                prevState = value;

                if (null != prevState && null != prevState.OnExit) {
                    prevState.OnExit( Owner );
                }
            }
        }

        private State<T> state = null;

        public State<T> State {
            get { return state; }
            private set {
                PrevState = state;
                state = value;

                if (null != state && null != state.OnEnter) {
                    state.OnEnter( Owner );
                }
            }
        }

        private List<Transition<T>> transitions = new List<Transition<T>>();

        public StateMachine(T owner, State<T> initialState) {
            Owner = owner;
            State = initialState;
        }

        public StateMachine<T> AddTransition(Transition<T> transition) {
            transitions.Add( transition );

            return this;
        }

        public StateMachine<T> AddTransitions(params Transition<T>[] trans) {
            foreach (var transition in trans) {
              transitions.Add( transition );
            }

            return this;
        }

        // ...

        public void Update() {
            var toStates = from transition in transitions
                           where transition.IsApplicable( State )
                           select transition.ToState == null
                           ? prevState
   : transition.ToState;

            if (toStates.Any()) {
                State = toStates.First();
            }

            if (null != State.OnUpdate) {
                State.OnUpdate( Owner );
            }
        }

        // ...
    }

For those worried about lost CPU cycles, it would be quite easy to store all the transitions which can start from the current state and only check those on each update, saving some time. It is also very easy to add fuzzy logic into the mix: just add a viability calculation on the transitions, and randomly choose between the possible ones, according to their relative probability.

And, finally, thanks to some fluent magic and variadic parameters, instantiating a state machine becomes something as simple as:

    class Entity : IStateful<Entity> {

        private StateMachine<Entity> stateMachine = null;

        // ...

        public void Initialize() {

            stateMachine = new StateMachine<Entity>( this, EntityStates.Idle )
                .AddTransitions(
                    Transition<Entity>
                        .FromAny()
                        .Except( EntityStates.Idle, EntityStates.Talk )
                        .To( EntityStates.Idle )
                        .When( HasNoTarget ),
                    Transition<Entity>
                        .From( EntityStates.Idle )
                        .To( EntityStates.Walk )
                        .When( HasTarget ),
                    Transition<Entity>
                        .From( EntityStates.Walk )
                        .To( EntityStates.Talk )
                        .When( IsTargetInRange ),
                    Transition<Entity>
                        .From( EntityStates.Talk )
                        .To( EntityStates.Idle )
                        .When( DoneTalking ) );

        }

        // ...
    }

Gains from Transition Machine

This implementation solves most of the problems from classic state machines:

Verifying transitions

To verify that a state machine is properly coded, you just need to check the transition definitions. If they match the design, errors are limited to the states or the design itself. Adding transitions and states only increases the definition code, but, it being greatly localized, adding errors is harder than on the highly distributed structure of the classic approach.

Reduced boiler-plate code

States now only care about what they actually do, whether they reproduce an animation, start an attack or scan the area. Transitions are also divided into smaller, independent conditions, so they require less code and are easy to debug. The state machine itself is now simpler, too, and no global states are needed.

No global states

They have been replaced by transitions which can start from one, several, all or all but a few states. And this can be easily expressed in a single line of code in the state machine's initialization.

Messaging cannot directly hijack

By not supporting messaging we have prevented an arbitrary source of state changing. Messages are instead expected to produce a change on the state machine's owner or its world, triggering the relevant conditions. Thus, a message telling "Honey, I'm home" would set "JohnyIsHome = true", and a transition could evaluate that variable.

State reusing

States can now be reused among different transition machines, since they are now independent from the machine they are a part of and the transitions from and to them. The only limitation in the current implementation is related to the generic type with which the state machine is defined.

Scripting ease

As a bonus, with this approach it is a lot easier to define a state machine as a configuration file in XML, Json or whatever, to be scanned and turned into a working state machine. You'd need to define identifiers for each state and condition, and build them at load time (probably using a factory), but that code would be simple enough and would let your designers (or even the coders) easily re-define the state machine without the need to touch the code.

Conclusion

I've presented a noticeable improvement over classic state machines, based on the separation of states and transitions. This has made them a lot easier to implement and use, even making it more scripting friendly.
To check a C# implementation (with no license at all), check the repository. In the future I expect to write a C++ implementation (which will be unfortunately way uglier and more verbose). If I find the time, I'll release a D version too.

Future work

The states in this implementation are still ungracefully coupled to their type parameter and that of the state machine. I intend to tackle this problem by making states depend only on the data they require to function, be that defined as an interface or an element in a flyweight context. I'll let you know when I find a suitable solution.

Acknowledgments

This would not have been possible if people like Buckland and many others had not collected their know-how and made it available to all. Only by letting others see our work can we expect to see it improved.

Of great importance have been my endles discussions and conversations with @cookingsource. Because of him, I am a better programmer. Also, most of the cool stuff you'll see in my code was known to me through him. But not Yoda conditions; those are all mine. And I love them.

Also, while writing this I've found several articles specifying similar approaches, although usually a little more complex. Check this for an in-depth analysis of short-comings on the usual definition of state machines, and a more complete solution to their problems. Documents like this one are also a big help when trying to conceptualize the nature of state machines.

Game Design Challenge: Wii U

2012-10-10T01:25:00.000+02:00

This is probably the fastest GDC submission I've sent. From inception to emailing in barely 90 minutes. And, surprisingly, I'm quite proud of it. Still, I can't avoid thinking I've seen a very similar idea somewhere. EVE: Dust 514? Somehow, but not quite. Nintendoland? I didn't know much about it until 20 minutes ago. Sanctum? Iron Brigade/Trenched? These focus more on the tower defence side of things.
Anyway, meet Squad Action

Squad Action: Working Title

SA:WT is a hybrid DOTA/RTS multiplayer game for Wii U which takes advantadge of the console's online platform and varied controller possibilities.

Teams of 2 or 3 players work together to destroy the enemy base while keeping theirs safe. Each team will count with one commander and one or two ground troops.
The commander surveys the battle ground using the Wii U Gamepad and its touch enabled screen in RTS fashion.
The soldiers play in the main TV screen, FPS style, using a WiiMote and Nunchuck. They will traverse the combat area fighting the rival players and structures.
In local games the TV screen can be split up to four times to accomodate 2 full teams (plus two Gamepads), while online teams can play from different locations and screens.

Resources are collected by soldiers while alive, at a rate of one unit per second (main advantadge of killing enemies), defeating enemy troops or buildings and disabling the enemy commander's droid. Most of the resources collected are sent to the team account and a small part is kept for personal use.
Ground troops can return to the base to buy basic equipment and heal, but they cannot upgrade their loadout. The commander can offer equipement recommendations and loan part of the team resources to a player, so she can acquire equipment out of her reach. These loans would be later discounted from the players' collected resources, trading a short term advantadge for future income problems.

Options available to the commander:
- Build gates, sensors or turrets in their half of the map.
- Upgrade soldiers' armour and weapons.
- Buy and drop temporal buffs almost anywhere on the map, which can be picked by allies or enemies.
- Place warnings or attack signals on the map. In local games these can be seen by the enemy!
- Browse available equipment and mark recommendations.
- Loan resources to team members.
- Deploy a remote controlled droid.

Remote droids are controlled from a FPS perspective in the Gamepad display. They have limited combat capabilities but are the only way to build the most powerful structures, repair damaged equipment or resurrect team members before their respawn time arrives. However, while the bot is deployed the commander can do nothing else and, should the bot be destroyed, they'd be unable to play for 15 seconds, or up to a minute late into a match. The bots can self-destruct without penalty, but it takes 10 seconds until the sequence completes, during which the robot cannot move and is open to enemy attacks.
The bot can also transform into a stationary turret atop the team's base core. These turrets are very powerful and provide extra protections to nearby allies, but turn slowly and if destroyed will damage the base noticeably.

The winning team will be the first to destroy the enemy base or reach a set amount of resources, depending on game/map type.

Update: SA:WT is one of this month's highlighted entries! I'm glad that someone has enjoyed my idea. One more for the list of pending projects!

Review: Rez (Q Entertainment/Sega/HexaDrive, 2001/2008)

2012-03-16T05:40:00.000+01:00

Platforms: Dreamcast, PS2, XBLA

In one of my first posts I exposed my distaste for the punctuation system used in videogames. As I said, my opposition stems mainly from videogame reviewer's reluctance to give marks below 6 and the 1 through 10 standard reliance on a mythical perfect game. This perfect game is, per se, impossible, and using it as a measure, therefore, pointless.
Although I remain adamant that perfection is unattainable, I request permission to exercise my right, as human being, to contradict myself by stating that Rez is, without the slightest doubt, a perfect game. Its perfection, however, does not arise from the impossibility of improving it -I'd gladly accept one or two extra areas on par with the ones available- but from the fact that any enhancement it received would fail to add anything to the experience as a whole. Rez can only improve by becoming larger, prettier or more literate, but none of these changes would make it any better than it already is. This is clearly demonstrated by playing the HD version available for the Xbox360. It looks better, sounds great, is panoramic and has a couple extra features, and remains exactly as good as the PS2 or Dreamcast versions ever were. I still play the PS2 and HD versions from time to time, depending on which one is at reach, and can't fault any of them.

Rez, gloriously low res

In trying to explain the greatness of Mizuguchi's magnum opus, let's get started by clarifying what Rez is not: a story game. What little narrative it has is implied in the hacker lines it displays from time to time and in the astounding* final area, and no more is needed. The tutorial, which is not that good, is more relevant than all the text present in the rest of the game, excluding "analyzation", "shot down" and "support item". Because those three arbitrary groups of letters, simple as they seem, are all this game is about: analyse all areas to 100% percent to unlock the next one, shoot everything that moves and collect as many power ups as you can. Why, you ask. Because the game encourages you to interact with those simple terms.
Players first learn to shoot. And shooting feels good because it produces a nice, simple note. Shooting up to eight targets at once feels even better, as it creates a simple and beautiful tune: duru-ruprup, turaruraru. As enemies get bigger or closer together, the rhythm and tone get more frantic, luring the player into the musical frenzy.
Collecting items is revealed to be important because they are obviously different and shooting at them just sounds better. As if that wasn't enough, accruing eigth blue items (less in later phases) transforms the avatar into progressively more detailed depictions of completeness and tranquillity AND awards you extra lifes. There is no indication of how many impacts you can sustain, but it can be instinctively guessed. Collecting red orbs turns out to be useful too, as each one, up to four, becomes a short-lived, powerful auto-shoot at your request.

It's mine, my precioussss

The other special item is identified as particularly important because, when shot, mutates from a probe into a shiny countdown box. Release a full blast on it and a rainbow congratulates you, followed by a surreal deformation of space and a new region of the level. Somewhere in the screen you read 10%, later 20%... and you just know you need 100%.

That's it. With just one verb (or one stick and two buttons), sound cues and simple graphics Rez is able to completely explain itself in the first five minutes of gameplay. As levels progress, the wording gets more frantic, but the meaning remains the same: the enemies are instruments and you have to compose art. The music and graphics, although fundamental to the game, never take the focus away from the core, and only work to enhance it.
Music is simple and integrates with the frequency and spacing between enemies. Your shots are synchronised to the music, and so is the whole of the screen.
The background and reticule are rendered in wireframe -and a subtle glow when aiming, so that enemies and other targetable objects can be easily identified. Enemies feature simple shapes, almost iconic, with the most distinctive being tentacled beings composed of hundreds of small squares. Whether this minimalistic approach was a matter of hardware limitations or a choice made long before development started I can't tell, by I can assure you that contention in the graphical area was the best thing they could have done.

Simply beautifil of beautifuly simple?

In the end, nothing gets in the way of the experience, but everything collaborates to make it deeper. And this is exactly what defines a perfect game.

Beyond shooting, Rez offers variety in the form of mutating levels, mixing different possible configurations each time a level is played. After dozens of hours spent in its world I am still surprised by combinations I had never seen before.

The man changes its behaviour depending on your proficiency

And then there's the fifth area, with its haunting beauty, melancholy and sensitivity, letting us know that videogames can be deep without breaking the definitions we use to constrain their possibilities.

Conclusion

I can't create the chart right now, but as soon as I can, I'll upload it. Spoiler: Rez is at the top and Child of Eden is dangerously close the bottom.

EDIT:

Here's the chart.

* Marvel has sadly reduced the word "astounding" to meaninglessness.

Review: Etrian Odyssey III: The Drowned City (ATLUS, 2010)

2012-01-04T18:23:00.000+01:00

It took long, but two days ago I finally beat The Drowned City's three endings, so at last I can say that this is, accompanied by Castlevania: Order of Ecclesia, at the top of my DS charts by a decent margin.

Etrian III is built like a good post-rock/post-metal/prog album or song, as any decent game should be. A common thematic undercurrent and instrumentation (story, mechanics, general rules) encapsulates the whole, slowly progressing so it never repeats itself, revisiting previous moments with a new twist, and always insinuating the breaking points when everything will come together gloriously. Also, there must be something unexpected inbetween, plus new things to discover when we decide to play the album again.
EO3 follows this rules almost to the letter, with its level design getting more complex as time goes by. All of the 5+1 strati our guild must conquer start conservatively, introducing minor changes to the basics and new monsters to get used to. Once the player got used to the new environment, new game elements are introduced in the following levels (new FOE patterns, currents, mission types or traps) to expand the world as we go down, one level after the other, always yearning for the next surprise.

EO3 also feels like the great comeback from that band that so deeply dissapointed you with their second album*. After identifying everything that failed in Heroes of Laggard, ATLUS removed almost everything new, refined the formula and added some amazing new tricks.
Once sea exploration, weapon forging and the new classes are introduced at the beginning, all goes back to old style Etrian, until the real additions are revealed half way through: a second city, subclassing and story branching come quickly one after another, setting EO3 as a whole sequel, instead of the expansion feeling that surrounded all of EO2. And, eventhough story branching seems irrelevant at first, it is later put to good use at the end of the 4th stratum, when the consequences of each choice are finally introduced. And with this the pieces are set for the final feature introduction: meaningful replaying in a proper New Game+ mode for the first time.
All this together manages to make this third entry in the series superior to the original, including its amazing revelation of the 5th stratum.

Princess, Ninja, Pirate. Add water. Mix.

Subclasses alone have such an impact on the way the game is played and exploited that it is the core of The Drowned City. If the series was known for the freedom it offered when creating a party, subclasses add completely new levels of customization, making it quite hard to share more than one or two combos with everyone you know who playes the game (unless, of course, you all follow the same guides and dislike independent thought). The most common combos would include a cross between Ninja or Buccaneer and a Zodiac or Arbalist, plus a Monk/Ninja or Ninja/Monk, but that's already a few possibilities. Add in the other options and you can satisfy most RPG players' dreams. And, to top it all, there are few and unlikely choices that would produce a party unfit to beat the game.

Another addition, although less notable, is the existence of invisible areas, where auto-mapping is disabled and in which FOEs don't show in the map. It is, however, quite a minor feature, requiring just a bit more caution and attention from the adventurers.

Things to iron out

Of course, Etrian Odyssey III is not completely perfect.

For starters, the experience system does not favour low level characters, so it is kinda impossible to finish the game using classes unlocked mid-game, unless you grind XP for days. It's a real pitty, because my Shogun was condemned to end all big battles dead, simply because I got tired of resurrecting a level 40 so-so shogun, my killing-machine-in-the-making, when the rest of the party were close to or at 70 and dealing about as much damage as he did.

First stop: death by giant bird

The sea faring, although interesting as a puzzle minigame, is not sufficiently linked to your progress through the labyrinth, so it feels detached from the actual adventure. The same happened with Persona 3, where the connection between story and dungeon crawling was way too tenuous, frustrating those players more interested in combat or school life alone. Persona 4 got that fixed, as I hope Etrian IV will, too.

Also, there are some times, mainly in the 3rd stratum (spoiler: awesome soundtrack), when the advance, find blockade, return to town, talk to someone, get to blockade again cycles are too frequent. It is specially frustrating in the second and third runs, when you already know what the outcome will be and only want to get as far as possible to the ending you wish to unlock.

It's all so post...

And then there's ATLUS' signature: post-game with absurd difficulty. There are, as far as I know, three optional elements: the 6th stratum, Cyclopean Haunt, where the Big Black Monster of Darkness resides; the Dragon God quest, comprising the Golden, Red and Blue dragons; and the post-game quests.

Meet Leviathan. Please, die now

Getting back to the rock album simil, Etrian III's post-game sections are a band's compilation of B-sides and unreleased tracks. Yeah, sure, there may be some great pieces in there, but most of the unreleased tracks are unreleased for a reason. Probably only the most hardcore fans will appreciate them and the time it takes to learn to enjoy their nuances. Also, there is a certain lack of purpose in such compilations, in which you usually find experiments, diverging ideas and not so funny jokes.

Cyclopean Haunt is so hard and complicated that most players will just try it and leave with a taste of blood in the mouth, after savouring the splendours of the basic adventure. The dragons and post-game hunts will simply leave people dumbfounded, wondering how are they supposed to defeat a monster able to destroy half their kick-ass, level 70 party in one turn. The amount of character resets, material grinding, levelling and memorizing required to beat those marks is just insane.

But, to be fair, the original Etrian also suffered from this problem/feature, built to give hardcore players something much harder to sharpen their teeth with. I reached floor 28/30 then and have so far gone down to 23/24 in The Drowned City (running away from ~30% of the battles). I'll probably attempt an assault to the Black Monster of Darkness, just to see if it kills me faster than the dragons.

Conclusion

Pending Dark Souls and Megami Tensei games

Perfecting and adding to the original formula, but keeping faithful to the basics of relative difficulty, wide party configuration options and low grinding requirements of the original, ATLUS managed to create a masterpiece of the dungeon crawler genre. Few games have been able to keep me interested long enough to finish them three times and experiment with so many different setups and combos. And the icing in the cake is the superb level design** and balance. The game lends so little help that players will never feel they're going along for the ride, but enough so that they won't regret going back into the depths after an unfortunate death. I wish I saw this level of subtlety in games more often.

* Muse's Showbiz, then Origin of Simmetry, then Absolution would be my reference. What's yours?

** I want to use this chance to ask every publication and award ceremony to create a new category for Best Level Designer and award its 2010 instance to all involved in the Abyssal Shrine design. Hard to master, easy to skip once finished and filled with interesting puzzles and thrilling ambushes. Superb.

*** Just so you know, my parties:
First run:
Elora - Monk/Ninja
Shorsha - Gladiator/Farmer
IAintCute - Prince/Hoplite
Dualla - Ninja/Zodiac
Shilock - Buccaneer/Arbalist

Also tried
Queequeg - Wildling/-
Tried to replace Dualla with
Nagato - Yggdroid/-, but didn't last too long.

Second run: replaced Shilock with
Rubio - Shogun/Buccaneer, but when bosses got too touchy Shilock came back in.

Third run: created several farmers: Willow, Vohnkar, Meegosh & Kiaya. Rubio never left the party and is still at level 53.

Too many bundles

2011-12-14T01:00:00.000+01:00

Cave Story seen by @naramura. Shared by @Nicalis.

Today, 14 Dec. 2011, a new Humble Indie Bundle has begun, barely a week after the previous Humble Introversion Bundle concluded. And with it, we've already had 6 bundles from Wolfire in a year: Frozenbyte, Indie 3, Frozen Synapse, Voxatron Debut, Introversion and Indie 4.

Add in Desura's Indie Royale bundles, with its 3 weeks cycle, UK's The Little Big Bunch, supposed to start today, and the fact that indie developers were already quite fond of selling their games in packs, and you have way too many offers like this in a considerably small territory.

Although I like the idea of selling games this way, which clearly works and benefits every participant, I'd like it to stop for a moment and take a breath. Think of the consequences this madness is bringing.
Right now, we live in an ecosystem in which players start wondering whether buying an indie game at release makes sense. If it is any good, chances are it will be sold with some other games at very low prices, even as low as 0.01€, in less than a year. Early buyers are heavily punished.
The standard price for games is also being established at a dangerously low margin of "as little as you want", potentially harming developers who prefer to set their one prices and use sales or gifts to attract new buyers as time goes by.

If anyone involved in this madness reads this, I urge you to reconsider. Keep the good work, release and promote bundles, but slow down. Don't burn the formula or your clients' pockets too fast, or the market will be saturated and possibly damaged. Now that the indie scene is starting to flourish, we must take special care that it grows strong and at a good pace. By watering it to much we risk rotting its branches and roots.

Disclaimer: I'll still acquire HIB 4, of course. It's the best bundle I've seen since Introversion's Anthology! And I love playing from Linux.

Roguelike Line of Sight by Eric Lippert

2011-12-12T18:49:00.002+01:00

Isn't it wonderful when two passions get intertwined in ways you never expected? The passions in question are Roguelikes and the C# programming language, joined in the person of Eric Lippert.

In this week's post Eric has tackled the problem of developing a line of sight algorithm for roguelike games, which he'll apparently follow with an implementation. An interesting read for programmers and players alike, which saved me the time required to read through the forums myself =) And don't worry, the technical details are not enough to blow anyone's brains*.

For those not in the know, Roguelikes are top-down view computer role games of unusual graphical simplicity (environments, objects and characters are usually depicted using ASCII symbols) and extremely complex worlds. The genre's identifying marks are random generated dungeons, permanent character deaths (the save file is deleted if the character dies) and cumbersome controls. You should check ADOM (Ancient Domains Of Magic) or NetHack, if you haven't already.

And Eric Lippert is a respected member of the .NET community, having worked on the compilers of Visual Basic and C#, and lately leading the development of Roslyn, an on the fly VB.NET and C# compiler and analyzer.

* Disclaimer: No guarantees regarding the rest of the blog. Tread with caution.

Fragmented lives

2011-11-19T16:55:00.001+01:00

Two days ago I watched, once again, Trois Couleurs: Bleu, the first movie in Kieslowski's Colours Trilogy. In that movie music is used to illustrate the main character's missing links with its family. And all the while I wondered: why do games so rarely use music and game elements to such effect. I've seen this done, from time to time, although not to its full potential, and usually limited to the music. Character themes and such.

But how could this be turned into something exclusive to video-games? The usual is removing characters which enable secondary actions (Beyond Good & Evil's partners, Dark Souls's Fire Keeper), or an object (Sands of Time's dagger), but I can't think of an instance in which the player's actual ability to interact with the environment was limited or bolstered by changes in the protagonist's motivation or expectations. Except, once again, Demon's Souls and Dark Souls' human/ghost/undead forms come to mind.

I'll give some thought to ways this could be accomplished, or other games I've seen something like this.

And that's it for today.

Running out of games to buy

2011-10-09T02:59:00.000+02:00

Update (2011-12-14): The way things are looking, STALKER 2 might finally include no "always connected" DRM protection at all. The dust is still setting, but GSC seems to have closed its offices. A sad day for Ukranian game developers and players all around, for sure. Please, guys, if you have the opportunity to finish the game, respect your clients and protect the game in a sane way.

Original post:

Today I have learnt that the next chapter in the STALKER (no more s.t.o.p.s., please) series will come with a little present: DRM requiring constant internet connection. Another thing I've learnt today is that I will not play that game. And that realization hurts, because I am a huge STALKER fan. I own the trilogy: Shadow of Chernobyl, Clear Sky and Call of Pripyat. The last two, I bought them on release date, and was proud of having supported GSC.
Why not buy STALKER 2? I will not accept been treated like a criminal by default, and I have already been bitten by this DRM stupidity. Clear Sky in Western Europe was distributed by Deep Silver, who slapped TAGES into it. TAGES, I found out, is incompatible with my DVD reader, and what did Deep Silver's support recommend? Get a new DVD. Haven't bought a Deep Silver product since, the same as I do with any company who betrays my trust.

But, sadly, during the last years my boycott list has grown non-stop. The videogame industry is becoming more and more unfriendly to its clients, constantly creating barriers between games and players: DRM, online passes, activations and even DRMed save games. The joy of playing is gone, replaced by the absurd requirement of registering, activating, checking the internet, writing codes and what not.
CEOs of the world: I am tired of all this. I don't see the point in giving money to your companies, when you only think of ways to make me pay full-price and give as little as you can in return. I refuse to ask for permission to play my games and I sure don't like having to rely on your servers, either.

After more than a decade of faithfully buying several games per month, I find my options limited, but not for lack of promising games, but for an excess of stupidity in the industry. I've gone from buying 3-4 games a month, even if I had no time to play them, to 1 or 2, with luck. And that average only holds because of independent developers and Good Old Games. For me videogame news are just a list of games I will not play, either because I am boycotting the company as a whole (Ubisoft), or because I find the security measures excesive (all the rest). And you read it right: not play. I won't even bother pirating the game, because I talk a lot about what I play to friends and acquaintances, and I will not give free advertisement to Ubisoft and company. You are not getting even an indirect sale from me.
Once DRM is removed, as happened with Mirror's Edge and Mass Effect, I'll gladly buy the game. But, most probably, by then I've already lost interest in the game and the publisher will have lost a sale.

Nowadays PC gaming is almost completely lost to me, and I fear that Valve's intentions to integrate Steamworks into PS3 releases will bring console games to the ground, too, as online passes are starting to do. If things keep going this way, I'll have to forget about playing, and bring books and movies back as my main hobbies.

And I won't feel sorry for any of the developers who forced me out of gaming.

League of Legends Dominion: impressions

2011-10-06T23:28:00.000+02:00

For those not in the know, Riot just released a new 5v5 game mode for League of Legends. It's selling point is that it is based on control points, rather than base defense and lane control, and offers a faster paced experience.

Short introduction

In Dominion each team base starts with 500 energy points and, each second, the team controlling more towers removes as many points from the rival's energy as the difference in controlled points. In order to make things interesting faster, Heroes start at level 3 and with enough currency for a couple of items, experience and gold are much easier to obtain and almost every fight is to death, especially the first encounters. This is because the time spent dead has been drastically reduced, to ensure players are more aggresive.

Is it any good?

It is fun, that's for sure. A match consists of 20 minutes of running around, attacking, defending bases, chasing and escaping, with the tide of battle changing easily. So easily that most games are won by very close margins. I have even lost a game to a team with only 1 point remaining.
But all this tension is continuous, without a pause or moment for reflection. While dead, you barely have time to look for your next item and buy it. There's no sense of progression, narrative or strategy, because all actions are more imrpovised than thought out. In this stressful environment communication is too difficult, to the extent that almost noone speaks more than monosillables. Also, the absence of secondary objectives, like guarding Baron Nashor's lair in the classic 5v5 map, takes away from the experience.

In the end, after a battle in Dominion, little more than the result is left. Each encounter in Summoner's Rift, on the other hand, feels like a story in which you evaluated your opponents and tried to counter their strengths, coordinating with your allies*. Also, since death is a lot more relevant, you learn to fear those characters which kill you in a breeze (Annie, Kata, hello!).
Like in narrative, the ideal is to introduce rest periods after moments of great tension, so the player can take a breath before going head first into the next fray. The tension must also go in crescendo, after each pause. This way, each new peak of excitement feels more pronounced**.
On the contrary, when exposed to constant action, as in Dominion, every new encounter is treated by the brain as the same thing, eventually losing part of its interest. If Dominion matches where any longer, it would soon become tiresome. Riot did well keeping things under 25 minutes, but even at that lenght I still get tired of this game mode.

Conclusion

Maybe Riot will some day manage to add extra depth to its new child, but until then it will probably remain a distraction from repetition. Its advantadge is that rival DotAs don't have a secondary game mode to break the monotony, once the competition from Valve and Blizzard arrives.
LoL's best card, its extremely wide and varied hero roster, might not be enough to fend of the attacks by itself.

However, I am not convinced that Dominion will save LoL from Valve and Blizzard's attempts at stealing its market share. The genre has a small fan base and big companies can do a lot of damage to Riot, through advertisement and simple brand awareness.

* Of course, there is always a black sheep who only complains about the noobity of the team. Welcome to the sad reality of online societies.

** Check Schell's The Art of Game Design for more about narrative in videogames. Or any good book about narrative, actually.

Adding replay value

2011-09-03T22:22:00.003+02:00

Today I'll explore the diverse mechanisms I've seen commercial games use to make them replayable or longer than it takes to end the main story itself. The main idea is that players are social animals, so they talk about what they play with friends, work colleagues or their families. The longer they play your game, the longer they'll talk about it and the more likely it is their acquantices, be them physical or virtual, will buy your game too. Of course, they'd better have good things to say about the time sink you've built: bad press does not beat no press at all in this kind of close relatipships.

Trick 1: Irrelevant secrets
Hide things not that relevant to the main story around, like ammo, modified weapons or photos of the development team. Players will spend a long time checking for secret walls or trying weird stuff. If their wild ideas succeed from time to time, they will keep at it. Otherwise, they'll stop trying and focus on the main game.
Pros: Easy to add.
Cons: They must be placed around evenly. Too many secrets or too few in one region of the world can create false expectations.
Examples: Any game with hidden power-ups or easter eggs.

Trick 2: Added background
Hide stuff which gives some insight into the world, the enemies or allies, which is not essential to ending the game. Jokes and logs fit well here.
Pros: Easy to add, since most of it should already be in the game reference documents. Role players love stuff like this.
Cons: Do not break the continuity. These extra dots in the drawing must be perfectly alligned with the ideas presented in the main game.
Examples: System Shock, FEAR, Baldur's Gate, Riven.

Trick 3: Super-objects
Hide game breaking equipment or abilities. Make most of them really hard to discover and even harder to obtain. If they are painfully boring to get, much better.
Pros: Bragging about the übersword feels so good.
Cons: Requires creating new items and/or puzzles. Most players are not willing to spend hours trying to achieve a secondary element.
Examples: Final Fantasy (VII, IV, V, VI, VIII, IX, X, XII...), Deus Ex.

Trick 4: Super-enemies
Add and extra challenge by including side missions with hellish fiends.
Pros: Once again, bragging rights. This comboes with Trick 3.
Cons: Make sure players understand they are not required to kill them and keep them away from the average player's path, or they will be very upset. Designing god-like monsters which can be killed requires a great understanding of your world's rules.
Examples: Final Fantasy, Castlevania.

Trick 5: Challenges
Add challenge rooms independent from the game whose only purpose is testing the player's ability. Time attacks or score rankings can hook players for a long time.
Pros: These are relatively easy to implement. Discarded levels, as well as parts of game sections can be reused.
Cons: It relies completely on your game being absolutely fun to play.
Examples: Batman: Arkham Asylum, Braid, Lara Croft and the Temple of Light.

Trick 6: Completion marks
Fill the world with riddles or puzzles which are there just to be solved. Nothing is earned from solving them, save reaching the desirable 100% completion.
Pros: They can be easily added to almost any kind of game.
Cons: If they don't integrate well with the world, the suspension of disbelief is at risk.
Examples: Batman: Arkcham Asylum, Castlevania (map completion).

Trick 7: On-line
Story be damned. Let's shoot at other players in the same maps until the end of times.
Pros: It works, often.
Cons: Competence is legion. Creating this along a single player experience is like building two different games with shared assets.
Examples: Call of Duty, Metal Gear Solid 4.

That's for no replayability at all. Now, how about starting the game again...

Patch 1: Play again
Do nothing. Just let your players start the game again.
Pros: It's oh! so simple.
Cons: If the game is unchanged, it has to be Jesus' second coming to get most people to play the game again, even years later.
Examples: Almost every game out there.

Patch 2: Now with passion
Restart with increased difficulty, usually in an infinite loop.
Pros: Good players will feel tempted to test their abilities against a harder challenge. But don't count on it alone to attract masses.
Cons: The added difficulty must be designed and tested too. It cannot be impossible, or players will feel cheated.
Examples: Super Mario Bros., Centipede, Space Invaders, Borderlands, Demon's Souls.

Patch 3: Unlock extra difficulty levels
Instead of restarting the game with higher difficulty, enable the option which lets players do so, if they so wish.
Pros: The number of extra difficulty levels is finite. Players are compelled to finish their first run so they unlock the new content.
Cons: Expert players who would rather play the harder modes are forced to play through Normal against their wishes, before they can face a real challenge.
Examples: Doom, Max Payne.

And what if restarting the game serves a purpose or adds something new to the experience?

Solution 1: Same old game with new socks
After finishing the game, unlock special equipment/abilities which can be used when playing the game again.
Pros: The game is unchanged and this special equipment is usually expected to break the game, making it easier or harder, so not much test is required.
Cons: How good or fun the replay feels relies exclusively on how the new abilities or equipment changes the experience of playing through the game.
Examples: Metal Gear Solid (unlimited ammo, invisibility suit), Castlevania (new characters with special powers/mechanics).

Solution 2: Secrets which change the game interpretation
Hidden elements can give the end of the game or some character's actions a whole new meaning. The ending remains the same, but not its meaning.
Pros: It is relatively easy to do and makes the world much deeper.
Cons: Replaying the game to watch a re-interpretation is not enough. This should be either very easy to reproduce or be accompanied by some other replayability boosts.
Examples: Blade Runner, Ico.

Solution 3: Multiple choices
Introduce mutually exclusive choices in your game, which modify the world or the way it reacts to the player. This can lead to different endings.
Pros: Players are more likely to replay the game several times if their choices shape the world.
Cons: This will require a lot of effort in design, asset creation and testing. If changes are too subtle, players might miss them, or feel cheated.
Examples: Blade Runner, inFamous, Legend of Mana, Chrono Trigger, Demon's Souls, Metal Gear Solid 2: Sons of Liberty.

Solution 4: Master of all trades*
A particular case of multiple choice. Let the players choose one among several classes, races, professions or specialities for the main character.
Pros: One game with different playing styles and experiences. Certain secrets might be only accessible with the right character, making replaying with a different setup more interesting.
Cons: All combinations must be able to end the game without great differences.
Examples: System Shock 2, Master of Orion 2, Etrian Odyssey

Solution 5: Randomize the world
Each time a new game is started some elements of the world are randomized. It can lead to different endings or maps, for example.
Pros: Each game can feel like something new, if the changes are perceptible.
Cons: Randomly creating coherent and challenging worlds is a daunting task, because players must be able to end the world in any possible configuration. You should add some choices, so the players have some control over the changes.
Examples: Blade Runner, Rogue (and all roguelikes), Dark Chronicle.

Any other possibilities?

* Thanks for the idea, Tommy.

Virtual economies

2011-07-10T13:28:00.000+02:00

When facing a rough problem it is common to study similar environments, looking for potential solutions. Virtual worlds, being all the rage, should have been the first place academics turned to, looking for advice, but they didn't, so I have the honour to publish my findings first. What can we learn from videogame worlds that would help us get out of this supposed crisis? After carefull study I've found that, apart from "beating the bad guys with the biggest sword you can find", there's nothing for us in here.

Really, videogame worlds have it much worse than us. Capitalism's main flaw is in its reliance and dependence on inflation to prosper, but worlds like Hyrule, Hillys or Final Fantasy Land are burdened with the much, much worse phantom of hyperinflation, and each tries to decrease its effect the best they can.

Origins of the inflation

One common issue in RPG worlds is the recurrent monster invasion, which brings chaos and suffering. It happened in each of the Phantasy Star games, in Hyrule, the Mana world... everywhere. But its direct effects are not that bad. I can't remember many towns destroyed by the monsters in any of those games, but what I remember is that all monsters, from cacti to dragons, drop legal tender, be it Gil, Rupees or Meseta, in generous quantities.
The direct impact of this simple fact is staggering: in whole worlds, when travelling from empire to empire, or even between planets of the Algo System, you'll use the same currency everywhere. Monsters provide the common ground for a planetary economic system that the UN can only dream of, with almost free manufacturing costs and little rewards for forgers.
The catch is that there is always new currency being coined, at an uncontroleed rate. If you want to eat roast vegetables, you just need to go out, kill a Giant Onion or Carrot, pick the loot and use it to buy the roasted version of whatever you killed. And the same happens every morning, in every house, in every town. And the amount of coins in circulation increases constantly, maybe not too fast, but in a year you might find that it takes killing two Giant Onions to buy one roast onion. And in a hundred years, when the next monster invasion starts, the value of the currency will drop so fast that it won't be even funny.

So how do you control inflation in a chaotic system like this?

Fighting inflation, the RPG way

Well, isn't it obvious? Introducing a control agent in the system, whose immediate task is to end the demonic outburst and bring tranquility back. Or isn't it? If that was the case, the problem would not be solved: by killing so many beasts, the hero will have amassed so much money that Uncle Scrooge would be jealous. But what if the hero is a tool used to burn money with? Pick a rude, introvert youthling with no grasp on economics and have him or her go around the world in ridiculous quests. That way, he'll obtain a considerable percentage of the world's riches. Then face him against all dangers you can come up with, including dragons, alien contraptions or crazy (sexy) witches. If you are lucky enough, he'll die in one of those fights, covered in acid or fire, devoured by fishes or teleported to deadly alternate universes. And the job is done: with the hero's body goes something like 90% of the coined currency.
If the hero survives this odds, figure a way to get rid of her: hibernation, deep psycological traumas or terrible accidents can help you. Otherwise, you might just teleport him to the future and let them figure it out.

The Hyrule way

As can be seen in the previous section, the problem is destroying the money the hero has earned without him realizing. But when the currency comes in big, hard to carry crystals, which diminute creatures leave around and inside any creature (just for laughs, I guess), the problem is more serious. For starters, the hero cannot be destroyed carrying as many on him, so that course of action is useless.
Hyrule came up with a pretty amazing solution: instead of killing the hero, keep him alive by destroying crystals. For this sole purpose, the Golden Armour of invulnerability was built. It achieves its miraculous effect only while there are crystals in the hero's possession, which are rapidly consumed.
And the problem is solved. Everytime the armour is activated, the Rupee is slightly devaluated. And by the time the mission is over, society can once again harvest crystals peacefully, until they need Ganon's help once again, the real hero of the Hyrulean people, willing to sacrifice himself once again for their sake.

The Italian/Pirate way

What if the Hero is convinced to spend all the riches in building a city noone inhabits really far, far from society, at laughable prices? If the town produces nothing by itself and, better, is isolated on an island, only the island's economics are destroyed, and since it has one unique owner and citizen, the problem is his to solve.
On the contrary, if, for example, through tourism, thievery and feminin services the town produces humongous riches, nothing is solved. You'll probably end with a crazy Italian buying whole city-states, a district at a time, until the system is out of control again. Only a huge war, founding a country and a new currency can save you from this disaster.

Might & Magic: Clash of Heroes (HD) (Capybara, 2011)

2011-06-21T21:57:00.001+02:00

Platform: PSN, XBLA, (DS)

The high definition craze is hitting with force this year and Ubisoft is making sure it is at the front line of this new fashion. In its zeal to outnumber anyone's HD rehashes it is now releasing re-skinned versions of one year old DS games. Well, at least they've had the decency to spearhead this new idea with a decent game, which did not get the attention it deserved. Unfortunately, the port didn't get the love it deserved, either, and it is just a port, with small fixes and brand new outstanding problems.

I will not go in depth into Clash of Heroes' mechanics and merits. To cut a long story short, it is an interesting and entertaining mix of your average tactics RPG with Magical Drop and Magic: the Gathering. Or something like that. It is quite unique. For more info, internet is full of reviewes of the DS original, and the modifications made to the new version do not invalidate them.
Regarding the common ground between both versions, I'll say that my favourite part remains intact: the puzzles, in which you are given one turn to prepare a number of attacks. They serve as tutorials for advanced configurations and how to best take advantadge of the rules. The bad is mostly the same, too: the last chapter is too simple and uninspired, consisting of, basically, going forward to advance, backwards to grind, fight the two final battles and that's it. Balance could also be improved, with random battles sometimes featuring too strong enemies for the current level of the player, or the level of bounties being inconsistent. Also unfixed is the possibility of losing bounty hunts without being warned, if the player decides to try a different one.

About the HD remake, I will say that the new art is, in most cases, great and very well designed. The only problem here is that some generic portraits are direct high resolution exports of the DS's vector graphics, looking like crude drafts in comparison with the rest. Also updated were several powers, units and objects, which were greatly needed. Things seem a bit more balanced now in multiplayer, which was absolutely vital for it to have a change to succeed. Also, the story mode difficulty has been reduced, but you'll still want to throw the controller a couple of times, specially during the last chapter.

Multiplayer is almost the only ocassion when the game's heroes actually clash

But the greatest difference with the original is not in gameplay. It is much more basic, and its impact so deep that it turns a very good game into a test of patience: loading screens. The DS version had them, in a way, but they were never longer than 5 seconds. In the PS3 and 360 version of the game, loading screens last from 5 to 20 seconds. And, given the mini-sections and battle arena design of the game, they are used way too often. And, usually, there is no more than a few seconds between each of these pests showing up. By the time I got to the third episode I was so bored of seeing them that I ended counting how long each took: the average is 12-15 seconds.

So you'll wonder: "How terrible can this be? Most games have load screens, and nobody complains*." Well, let's say I find a bounty target I have to fight. The sequence would go like this: talk to the target (5 seconds), accept to fight(2s), loading screen (12s), actual fight (2-5 minutes), loading screen (12s). OK, the bounty has been hunted. Let's report back: exit the current map (5s), loading screen (15s), go to next map (5s), loading screen (15s), go to tavern (5s), loading screen (15s), report and get new target (10s). And now go back to were I need to go, which will require at least a couple more area changes and the corresponding loading screens.
So, of the, approximately, 70 seconds it took to report back, I've spent 45 looking at a loading screen, and one whole minute of the last 7 of gameplay was spent in them. After a couple of hours of this madness I had already started to decide what to do and where to go, not based on advancing the game or collecting the most objects, but on minimizing the number of loading screens I'd trigger in the long run. And still I have the impression I spent about 25-30% of my 40 hours of gameplay watching the dreaded "Loading..." text.
Of course, the game quickly stopped being fun. Only the battles kept me attached to it, as they were several minutes of blessed uninterrupted joy.

Boss battles. Nightmares are made of these.

I'm sure someone in Capybara said loading took too long and the reply was "Nah, it's not that bad. And the cost of making them shorter would be too high". And that phrase there damned the game. I had a similar experience in my first job, with a tool I co-developed, which was barely usable because of load times. We tried to lie to ourselves saying it was not that bad, too, but once we managed to fix the issue (much simpler than we expected), we could admit the truth: there was no way anyone would use that tool the way it was.
Capybara should have accepted the criticism and worked until a solution was found. It might have been as simple as using a second core to decompress sound effects, which I'd say is the cause of the issue. Or more complex, like rewriting the whole asset manager. But it would have been worth it, if they managed to make the game as entertaining as it was on the DS.

Conclusion

I couldn't come up with many similar games...

Since Capybara and Ubisoft wouldn't care to redesign the game core to get rid of or, at least, improve loading times, I have to recommend to stick to the DS version. The changes are not that great, exploring is not a despairing experience and you can find it for way less than the new price (15€ for PS3, 1200 points for 360). And, most important, you won't be rewarding laziness and low cost ports of games.
For my part, this and Beyond Good & Evil are the last and only Ubisoft HD versions I'll ever buy. After giving them a chance, I will not make the same mistake again. I'm even considering cancelling the Ico + Shadow of the Colossus pre-order, in case Sony turns out to be as cheap as Ubisoft in these matters.

* I can only remember one other game I hated as much for the same problem: Star Wars: the Force Unleashed, which had loading screens in the options menu and character customization screens. Of course, The Force Unleashed is one of the worst games I've ever played, while Clash of Heroes (HD) could have been a great game.

Review: Mass Effect 2 (BioWare, 2010)

2011-05-07T03:07:00.001+02:00

Platform: PC, X360, PS3

Mass Effect, the first game in BioWare's intergalactic saga, turned out to be one of the best RPG blenders of the past decade. Despite some flaws, it might even be one of the best in video game history. It is up there with System Shock and Deus Ex, becoming part of a trinity of very different games with very similar concerns, each of them a testimony of how far available technology could go to create believable environments, characters and plot, and how to take advantadge of constraints.

System Shock, Deus Ex and Mass Effect have something else in common: their sequels departed considerably from the original. In System Shock and Deus Ex it was, mostly, a matter of technology and standard shifts. System Shock was released when the FPS genre was still crystalizing and its, admittedly overcomplicated, control and inventory schemes failed to become the rule. Deus Ex 2, on the other hand, changed the reference platform from PC to the booming console market. In both cases, the result was a considerably simplified version of the first game. However, Looking Glass used the opportunity to create a completely new kind of game, while Deus Ex: Invisible War remained a dumbed down version of its predecessor.

System Shock 2 is nowadays a classic, while Invisible War is just not.

Between Mass Effect and Mass Effect 2 no such technology or standard shift happened. All the modifications to the formula were the result of fans feedback, internal development and, I guess, some pressure from EA. And those changes left a mark even bigger and scarier than anything done in Deus Ex: Invisible War.

What happened?

Sequels of the world be aware of the tale of Mass Effect. Quite a start for a saga, raised from illusion, care and depth, by many loved, despite its flaws, into change it was compelled by EA's suits and internet boards.
Not too good a shooter nor much of an RPG, that was its cross, but the way of the bender was never meant to be easyly walked. Still it sold in the millions and, once DRM was gone, I bought it and rejoiced.

Things looked bright for BioWare and its new step-father, dollars in the pocket and still two sequels short, there was much to win, while little could be lost. Yet, greed took its toll, Mass Effect 2 was rushed to market, changed for the sake of change, dumbed down to please the masses of FPS, TPS players who about Mass Effect complained.

"The Mako is plainly a bore, with little to do in outer worlds, the arsenal too ample, the stats a ton, too much to watch and learn, overheating weapons are plain odd, and why is not Tali in my bed?"
"Just let us run and gun, the next gun better than the rest, picking weapons' not that great. I play to have some fun. Oh, and could you add some mini-games?"

Someone compiled all these requests, wrote them in a chart and forced them into the game. They might not fit well, or needed more thought to blend, but the release date must be met. "Just work less on the PC port. Like anyone will care."

And Mass Effect 2, my friends, is what we have left. By the way, this is the farthest I could take all this prosaic verse.

Port of Citadel...

Where to start? Let's take the platform out of the picture first. I played the PC version of the game, developed this time by BioWare, instead of Demiurge. It happens to be one of the worse ports I have ever stumbled upon. The engine runs smoothly, though it could be argued that textures are not that good, nor models so complex, but I've seen real nightmares in engine porting. Still, the list of problems with the PC version is preposterous.
Having put so much work into making sure the game ran properly on PCs, it is hard to understand why everything else is so ill thought. Using menus in Mass Effect 2 is slow and awkward, as two basic features such as double click and the mouse wheel are nowhere to be seen. To make things worse, Enter and Esc are seldom enabled in menus to speed up interactions.
There are also problems with remapping not working or only partially, which were not fixed until the second patch, more than a month after release. And on screen instructions are still unaware of remappings and only the default controls are shown. The game keeps prompting me to press Space, when the actual Use key is now G. I think I had never seen something like this since the beginning of the XXI century.

First Contact

The first thing most Mass Effect 2 players will do is importing one of their Mass Effect characters over. And, from the very start, problems start arising. Given how Mass Effect ended, it is quite possible that players finished the game at least twice in the same day, to check the outcome of the most important decission taken in the game. Some might have gone further and replay the game from certain mid-game points, were other relevant decissions were made.
These players will now have several profiles available of the same character, with similar levels and dates, most as old as one or two years.

The developers of the import system apparently gave no thought to this possibilities, as the players get no information whatsoever on the profiles they can choose from. Not even a date. I expected, at the very least, the game date, a photo, a list of the most relevant choices (Saved the Queen? The Council? The Krogan? Did Shepard propose a council representative?) and who was Shepard's love interest, if any. Shepard's stats sheet would have been welcome, too.
None of this was available until after the profile has been chosen and, strangely enough, there is no "Cancel" or "Back" button to be found at this moment. The only way to choose a different profile is quitting the game, via Task Manager (Alt+F4 does not work), which is far from ideal.

And, to make things even worse, the player was not allowed to check some other information about the profile until something like 20-30 minutes of introduction and tutorial gameplay, when Shepard is briefed in not very conclusive terms. If you had chosen the wrong profile, you were welcome to try again, but the introduction was unskippable, so you'd better choose the right one the second time around.

The failed import mechanism made for a frustrating experience from the onset, and an omen of things to come.

I must say, nonetheless, that the device used by the design team to reset Shepard's character is well thought and elegant. But they have the problem that they now should come up with a new way to perform the same trick in Mass Effect 3, without repeating themselves.
And, of course, Shepard's reconstruction does not explain why the recurring characters, Tali and Garrus, have forgotten everything they learnt on the first mission.

Someone stole my Role!

Now, for role elements: stats are reduced to six, plus one you can earn by importing a character. All weapons proficiencies are contained in one single stat, which also increases the effects of Paragon/Renegade. I am still trying to decide if there is a relationship I don't see, or if said stat is the "throw everything we could not fit in this stupid limit."
Improvement points are awarded onle after each mission ends, making progression laughable, and have varying costs of 1, 2, 3 and 4 points, which makes things even less natural. You are often forced to not improve Shepard for several missions, waiting until 4 points are available. In my Mass Effect review I explained my preference for more continuous systems, but BioWare decided that big, too noticeable increments would be better.

There are also no longer differences in weapon proficiency among classes. Every class can use any weapon with pretty much the same ability. Soldiers and other combat oriented classes have a couple of extra improvements, but that's about it.
The funniest thing is that soldiers and such have very few abilities per se, so they could have special ones which turn them into deadly users of specific weapons. Instead, most of their already limited stats are dedicated to elemental ammo. Because, believe it or not, only they can use special bullets, which take the form of sustained abilities. Other classes can only access those clips if the soldier masters the specific kind and learns the power of love, with which special ammo can be shared. Low level soldiers must be greedy, unlikable people, I guess. And then, all your party shares the exact same ammo. If you find yourself fighting groups of enemies with several kinds of protections, e.g. robots and humans, you can't have different party members use specially targeted ammo.
In Mass Effect I used ammo effects to create synergies, like poison + incendiary + shield piercer, which heavily damaged enemies. But in Mass Effect 2 strategy has become much more... non strategic.
This elemental ammo abilities, I must say, is the most ridiculous equipment system I've seen since Final Fantasy XII's licenses.

And the tale continues... not

The other selling point for RPGs is their story driven adventures. They usually tell grander tales due to their option to include levels of exposition any other genre would simply reject. And there is a lot of exposition in Mass Effect 2, be sure. The universe is detailed, with new species, ruffians and places to discover. But all that content leads to a depressingly underwhelming closure.
At the end of this part of the adventure so little has been achieved that it feels as filler. Don't misunderstand me: I find the information you gather interesting, but it remains just information. The Reapers are still as unstoppable as at the end of Mass Effect, the Citadel Council remains as stupid as ever and the Earth was screwed anyway. The universe is unchanged, the saga is no closer to an end and after finishing the game I felt I had spent 40 hours in something that would have been much better as a smaller part in something bigger.
It would have worked perfectly as a submission in a more complete game, or even as DLC (which I would have not played). But as a stand alone chapter in Shepard's life, it lacks the relevance to become a novel.

Development, development, development

And the third pillar in the realms of role playing games: character development. Not of the main character, usually, we have got used to that in videogames, but of companions and enemies. Shepard's only improvement over the story is that which the player wishes to instill in him or her, because otherwise little changes from Mass Effect 2's start to its ending.
For example, in my mind, Sharen Shepard, my blonde female soldier, started her journey in the original Normandy as a racist commander who mistrusted half of her partners, but is slowly getting used to them and even liking them. She will still keep her sentimental life tied to humans, but now befriends a couple of aliens. She is not completely bought into the Elusive Man's human supremacy ideas, and doubts she did the proper thing sacrificing the old Council.

Now, be honest: how many of you, players, give so much thought to your in game motivations? Before choosing an answer, do you stop to consider what would your Shepard do? Or do you just evaluate the rewards/penalties each option could lead to? Most people will not give a shit about stuff like background, and none of the Mass Effect games promote playing that way, to the extent that poor Sharen is being penalized for not having a black-or-white morality. Her dialogue options are reduced and access to specific talents limited, because BioWare encourages players to always answer in paragon or renegade style, consistently, no matter the morale stand point.
Mass Effect 2 gives a little more freedom, having enough morale choices to fill one of the branches and a good deal of the other, but it still presses the player to take extreme positions.

The worst offender is the quick time morale events, which most often than not give a poor idea of what Shepard will do if the event is triggered. Not playing them gives the impression of failure, a sensation increased by the insitency with which they shine, so most players play along with their alingment of choice, even if they do not approve of Shepard's actions.
Another problem is that some timed events feel barely related to morale. If I have a sniper rifle, an enemy on sights and shoot, how can it be a renegade action, when I've killed thousands of enemies before without shaking a bit? I would have killed that robot 5 seconds later, anyway. And let me ask: a robot? Now killing robots is wrong, but not so shooting mercenaries, soldiers and cartel members?
Or maybe I'm wrong and the renegade action was shooting a rifle belonging to someone else. Could that be some weird Canadian social taboo I'm not aware of? As I said, there is little information about why a given action should grant paragon or renegade points.

So Shepard only develops as a character as much as you let your imagination go. What about the rest of the party? Well, yes, they do change throughout the story, as Shepard intimates with them. They way it works feels a little strange, though.
But that is another story and shall be told in a later post.

Next time, in GameNotGame

"Oh, father, where art thou?", "The more things change, the more they stay the same", "The life and opinions of Shepard, mineral scouting ship commander" and much more.

Review: Shadow Complex (Chair Entertainmente w/ Epic Games, 2009)

2011-03-29T04:29:00.000+02:00

Platform: XBLA

Shadow Complex is the first serious and successful attempt at recreating the feeling of oldschool 2D exploration shooters inside a 3D canvas. It's plain to see they focused on recovering everything good from Metroidvanias, while removing the design flaws and problems arisen by hardware limitations. A new aiming system, leveling bonuses or an attempt at story-telling are some of the additions they made to the Metroid formula.

A bit of history

Since the introduction of the third dimension in videogames many attempts have been made to recreate the classics in the new environments. Most of the time, however, the results have been underwhelming. The fast action available in simple 2D worlds proved constantly too much for the more complex settings required for believable 3D scenarios, unless action was limited to only two axes (Robotron X, Einhander).
Until Zelda 64's lock on was introduced, few had managed to get things slightly right. And even after that, failure has been pretty common. Proof of this is the respected Castlevania series, which, after four 3D iterations, found commercial success only when Mercury Steam decided to break with the old game style completely.
The Metroid series did better, with the Prime saga achieving almost unanimous praise, thanks to its merge of FPS mechanics with a lock on system, plus subtle story-telling. It did, however, rely on completely different gameplay and narrative styles than its precursors.

There is, as can be seen, a common thread going on, which is not even considering a return to the 2D. That approach has been left for handheld consoles, with the Metroid and Castlevania series for Nintendo systems, or remakes of old classics and shoot'm ups, like Ghosts'n Goblins for the PSP.
Of course, there have been constant homages, with 3D games re-creating 2D gameplay in small sections. The one I remember most vividly is Nier, which achieved levels of meta-gaming off the charts. Castlevania: Lament of Innocence and Metroid: Other M also played with pseudo 2D, although not too succesfully.

Chair Entertainment played it safe, making Shadow Complex a 2D game inside a 3D world. Movement is limited to the x/y plane, while enemies are free to move all around. As a result, Jason, the main character, is allowed to shoot in any direction too. The game automatically chooses how deep you are aiming, and it seldom does wrong.

Metroidvania at heart

Shadow Complex is probably the highest profile metroidvania ever done: edge technology, a big studio devoted completely to it, an expensive marketing campaign and the push from Microsoft. The studio dedicated apparently several months redrawing levels in paper form, calculating possible advance routes, secrets placement and planning all kinds of distractions to get the player off the track.
Also, the Metroid games were studied to he deepest detail, until their inner workings were grokked by the team at large.

The game shares a similar system of weapons and suit upgrades or ammo and life increments, adding some more to the mix. Missiles and super missiles are replaced by grenades and... missiles. Gone are all cannon upgrades, with only the ice ray remaining in the form of the foam gun.
These three weapons are used to unlock doors, but in a more intelligent way than Metroid: Other M used. Doors are destroyed or disabled, and once open remain that way. Shooting to open normal doors was, appropriately, considered unacceptable and they now open as you approach.

Behold the power of the Foam Gun

Other upgrades include the armour increments, which improve defence, the passkeys, needed to unlock a game breaking piece of equipment, and gold bars, to gain access to special versions of all weapons. The rest are the more usual double and triple jump, super speed, hook and scuba diving mask. Oh, and climbig gear, without which Jason cannot grab onto ledges. So that's what Samus was missing before Fusion!*

You can see there's nothing too fancy in here. A couple of long needed fixes to the mechanics of the game and a little revision of the game items.

* In the Metroid series, Samus Aran, the main character, couldn't grab ledges until Metroid Fusion.

What's new, folks?

So, what is so special about this game. Well, there is a levelling system which, apart from improving the character, also unlocks special features. The most relevant of them is reached at level 20: the whole map is revealed, something I'm not a big fan of. I prefer a more classic approach, like improving the second playthrough with special items marked in the map, plus all visited areas covered. Knowing everything the first time around makes obtaining the 100% mark too easy, reducing the interest of further replays. It does not break the game, but was not really necessary.
Other upgrades obtained by levelling up are, however, more interesting. The character stats are improved on each new one, and every ten levels you get an additional life deposit or infinite ammo for one of your special weapons.
Experience is earned by killing enemies, obtaining secrets and items and discovering new areas of the map. The latter is, certainly, the most important, followed closely by boss encounters. Special kills, like headshots, add an XP multiplier.

A simple melee combat system has been included, allowing you to quickly dispatch enemies with a button press, if close enough. Small robots are punted, which is funny. Falling inside a group of distracted folks and madly pressing the melee button is probably too effective, as Jason is inmune to all damage during the animation, but the risk of getting into close quarter combat asked for such a compensation.

The flashlight replaces the diverse mechanisms used by Metroid or Castlevania to reveal secret passages. It is, also, a lot more relevant to the game. From the very start the player is required to break shafts or hatches, which are coloured when illuminated, identifying the kind of attack needed to open them. This is an elegant solution to an old problem, and allows Chair to use shortcuts much more often. It is, as well, way more comfortable than the X rays or familiar from Super Metroid or Symphony of the Night.

Your first big encounter and one of the few interesting ones.

Boss encounters are other notable change in Shadow Complex. With the exception of the first two bosses and the last one, which require a little bit of puzzling, all the rest are simple badass fights. It is a sad dissapointment, given the tradition of the genre to include complex enemies. What's worse, after the excellent Order of Ecclesia demonstrated how to design outstanding boss battles, expectations were even higher.

The most evident missing feature to long time players of the genre will be, however, a fast travel mechanism. Metroid allowed moving from one area to a distant one using elevators, which forced a certain symmetry between levels. Sometiemes this feature was used to allow fast, partial glances at areas still unreachable.
Castlevania games employ teleport rooms for this, which give more freedom to the designers.
The reason why Shadow Complex does not include any of them is not very clear. Travelling between distant points in the map is relatively fast, but usually involves very long and concoluted paths. Since the fastest way to move in the game is using the outdoor environment or the lower section, a couple of elevators connecting them would make things much better.

And last, the most irritating issue I have with Chair's game: teaching how to use new weapons by reading some text is not elegant at all. Super Metroid, the best game in this aspect, made the learning process part of the world design. Samus learnt the effect of its super speed and its special abilities by copying the behaviour of a creature. Different games in the saga have used the fauna in different ways, always creating a more real and coherent world.
Shadow Complex would have just needed to add a second Omega Armor, used by an enemy, the same way that Fusion did. Learning from a seemingly invincible enemy to finally beat it is one of the best experiences the developers could have gone for.
At least, they introduce some life into the environment by letting you snoop your enemies' daily conversations and jokes. They even make you feel regret for killing a hundred or so in an indirect way, in one of the greatest moments in the adventure. And it works to make you feel part of the world, but it is still a simple, lifeless world, in which learning is achieved by reading in a sub-menu.

Conclusion

Going head to head against giants is never easy

Shadow Complex is, in the end, a very entertaining and well designed game. Most of what it does improves on its predecessors, and some of its innovations work really well. Sadly, a couple small omissions and design oversights take away from the innovative whole, leaving it as a great alumn to its masters, but not a real contender for the crown.
Maybe the next one trying this formula will learn from Chair's mistakes and brings new life to the genre, now that Nintendo and Konami are clearly refusing to support it. I'll keep waiting for a worthy succesor to Koji Igarashi.

Review: Mass Effect (BioWare, 2007), Part 2

2011-03-28T03:06:00.001+02:00

In my previous post I got into the shooter genes in Mass Effect, explaining what it did well, what did not and what compromises were made to please a bigger market. This time, I'll review the RPG in it, plus the setting and story.

Looking through the RPG lenses

Role-playing games are built on three main aspects: story, character stats and world interaction. The tighter they all feel, the better the final experience should be. Or, in other words, no matter how good your game is implemented and thought out, if those three pillars do not support steadily the game as a whole, the RPG player will notice.

BioWare were greatly experienced in managing all three elements, and it really shows in Mass Effect. The story starts well and ends better, with enough stops along the way; the world is complex and astonishingly detailed; the main character can be differentiated beyond genre, clothing and faces; and there are plenty of NPCs, secrets and things to pick up.
Let's talk about each of them with a little more detail.

Universe and story in Mass Effect

There are a lot of things to learn in this new Universe humanity has recently (35 years ago) discovered. Lots of worlds, life forms, political bodies, rebels... Almost anything. Many of them are presented as the plot or secondary quests advance and other times it is just in the form of codex entries. It is true that, pretty often, Shepard's ignorance of the most basic information of important issues is startling, making the exposition a little too evident.
But, most of the time, the player is simply provided some new info, readable on the menu, which add a lot of flesh to the limited bits of info the story forces on you. And, believe me, there is a lot of info in those codex. Every extraterrestrial race, coalition, political group or history event is explained in there. Quite a lot of the many hours I spent on my first play-through were spent reading every little bit.
And if that is detailed, wait for the moment you reach another planets. Each planet, no matter how irrelevant or small, has a description of formation, nature or civilization. And, what's even better, many of them are homages to sci-fi classics. Trantor and Dune are among the most recognizable, but there is space for many other plays on the genre. Quite a delightful time waster.

And the story does not lag around. I'll avoid the details, but the events progress smoothly, even when the player is allowed to play the middle section in whichever order she decides. There is a lot of conversation involved, but most are so well integrated with the events at hand that they come naturally.
The beginning is epic, and leaves many doubts about what is really happening, and as it all plays out, you start filling holes, discovering new, bigger ones and spending all the time intrigued about the possibilities. And when the final revelations come, they do with a vengeance. Lots of loose threads are tied, and even stuff you thought was only there for the looks is revealed to play major roles.
The last great conversation, right before the final assault, is delivered in such a high note that I was simply unable to pay attention to all the action coming after it for a while. It is one of the best moments I've experienced in a sci-fi work.

The biggest downside to this masterfully detailed universe is that the actual playing areas are not up to par. No matter how detailed a world's description or old a spaceship is, there are only so many models for each. There are exactly three variations on facilities or caves and one world gravity. Variety is added by placing crates and closing doors, but the general scheme is the same, so there are no surprises left after the fourth secondary quest you play. It is a real pity, because the amount of detail in the main plot areas is so high that the other locations feel cheap. I don't know if this is the result of time or memory constraints, but a better solution would have been greatly welcome.
Anyway, as I said, plot related worlds and stations are as complex as any decent RPG fan would expect. To make things better, those worlds shake things up by introducing Mako areas to travel between far away locations. These are short and not difficult at all, but quite entertaining, as you keep getting in and out of the vehicle to get loot, open gates or talk to characters.
Confession time: I am a fan of the Mako and how it is used in Mass Effect.

Character stats

One of the defining elements of RPGs are, at least for me, the depth of the character development system. RPGs are about making my own decissions and accepting the consequences, making each adventure look unique. I expect to have an adventure I can call my own: re-telling key events as they played out for me is part of the fun. How I solved a particular problem or combat, using particular abilities feels more fullfilling if the person you are talking to used a completely different approach. All players share a common general story, but the details make each one's personal.

So, in Mass Effect you get a lot of different options to affect conversations, combat and treasure hunting. There are different weapon , class, spectre, conversation and powers stats. Many of them are limited by character choice, but even two characters with the same options can be played in diametrically opposed ways. The level of character depth offered by BioWare in this ocassion is beyond all expectations.

Sharen was a no-bullshit soldier. She had a thing for Ashley, but lost her chance.

And the same goes for your partners. You can let the game use the default levelling trees, or you can micro-manage each party member to fit your particular strategy. The impact is pretty much limited to combat, but it still makes a difference.

My only issue with the way this works is that, for a long time, I stopped feeling that point stacking is a good way to do reflect that. No matter how many enemies I shoot or locks I open, experience gained that way should not be assigned to bartering or sentinel powers.
Contact, Secret of Mana and some other games have experimented with constant stat upgrading. Attacking with swords enough times improves your dexterity and damage with such weapons. Receiving damage improves your defense and life over time, while dodging attacks makes you harder to hit.
Results have often been underwhelming, often leading to unbalanced gameplay, but it is about time one the big guys stepped up and provided a working implementation of this system. I thought it would be BioWare, but they decided to play it safe and tweak an already controlled system to perfection.
Fortunately enough, each time you level up you are allowed to assign a new ability point, so progress is constant and short-term goals (unlock a new power, max a weapon) never feel too far away.

Interaction

No matter how deep and detailed a universe is, if it is only in display, it is lost. If I am not allowed to distort, break or manipulate it, it might as well not be there. Games are about interaction, and RPGs are required to go beyond the average: their worlds must be alive and consistent, properties which can only be evaluated by forcing them to the limit.

This is were Mass Effect truly shines. An inmense amount of worlds to read about, all easily reachable through a simple interface. An easily grasped conversation system which, usually, plays exactly as you expect (it doesn't in one important conversation, which was quite frustrating). Dozens of interactive NPCs which play a part in the story, 6 party members plus 4 crew members compose the main cast for the game. Most of them play a minor role, of course, but the depth they add is unmeasurable. Their objective is usually revealing some information on the workings of the world, details of the main story which it does not delve in for long or just plain old jokes or social criticism.
Many of them will also trigger secondary missions. And these will also make other NPCs appear, or turn into radio boradcasts during the elevator sequences. No matter what people say, hearing your adventures in the form of news is one of the best loading screens I've ever seen.

Then there is the matter of your squad. Six different characters, with completely different backgrounds, interests and approaches to the events on the story. From time to time, talking to them will reveal new information. If you show enough interest, they might open up and ask a favour from you. How this conversations evolve is unique to each of them. Tali is mostly an information hub on her admirable people and way of life, Wrex's conversation is a mine field you can never traverse undamaged, Liara is a nice, nerdy girl to talk to, while Ashley is a defensive soldier afraid of losing her merits because of her family ties.

You can tailor you party to overcome Shepard's weaknesses

Sometimes your squad members will start conversations among them, adding more colour and detail to their relationships. Unfortuanetely, after playing Dragon Age and, mainly, Nier, Mass Effect's party chat could seem sparse and simplistic, but only because the other ones were incredibly focused in adding content that way.

Explaining each character like this achieves little to show the immense detail some of them have, specially in the character of Tali. She is so believable that it's no wonder she is a fan favourite.
During chats and cut scenes, Tali's reactions to Geth subjects are always visceral, as is her love for the migrant fleet. But there are cracks in there, making her personality much more interesting. She has regrets, doubts, heroes and hopes, and they show in subtle ways and changes in her voice tone.

Intriguing story + great personality + veiled identity = love

It is true that Tali is, with Garrus, the most interesting character you can recruit, but the rest, while sometimes a bit corny, do not lag behind.
There is, however, one exception: Kaidan Alenko. I was unable to have more than two conversations with him, with all the crying and poor little boy stories. His story and personality just played the topic, and I did not feel like losing my time with that. But with so much going on, a mistake can be easily forgiven.

Of course, all these interaction options would be worthless if their effect on the game was limited to themselves. But it is not so: many quests have more than one possible solution, better suited to different gameplay styles, and with slightly different outcomes. Many of the choices made are, however, not relevant until later in the story, or even in the saga, with some events making a mark in Mass Effect 2 and, hopefully, Mass Effect 3.

Conclusion (RPG)

No 'Is Fallout a shooter?' jokes here

BioWare know how to do things, and they showed creating some of the most engrossing worlds and characters in a game. The number of possible variations from one game to the next is considerably high, with options and choices which usually feel and are relevant.
Add a great story and exploration rewards and you get yourself one of the best gender benders since System Shock 2.
There are things to improve, of course (animations, some voice acting...), but overall it is an amazing product of love and craftmanship.

As a side note, I'd like to compliment BioWare for releasing a patch which removes the absurd activation system originally forced into the game. I bought the game only after such annoyance was fixed. If only other EA studios were this kind to their clients...

Review: Mass Effect (Bioware, 2007), Part 1

2011-03-15T03:52:00.000+01:00

Platform: PC, Xbox 360

It's hard to talk about Mass Effect without getting myself into a full-blown article on BioWare. A long loved company focused in a long lived genre, maintaining it while it slowly loses ground to the new guys in the party. In my mind I used to paint them as fairy tales knights, with shiny armour, declaring eternal love and care for the target of their affections.
And still, I cannot be considered a great fan on this company. Simply put, I haven't played that many of their games. I loved Baldur's Gate, but never played its expansion nor its sequel. Years later I tried Neverwinter Nights but found it too dissapointing, so I left it after 2 hours or so. Knights of the Old Republic and Jade Empire went by and I haven't played them yet, although I really want to.
And then, Mass Effect and Dragon Age came, which would be the last independently developed games before EA acquired the studio.
Yet, until very recently, I still respected the BioWare logo. It is possible that the cause was mainly my associating them with Planescape: Torment (Black Isle Studios), plus many friends of mine love their games and are constantly relating how they abused Baldur's Gate 2's magic and critical systems to destroy dragons in less than a D&D combat turn.
It's funny: most good memories I have of BioWare are actually not mine.

Mass Effect is, in few words, the evolution of BioWare from the complexities of its original Baldur's Gate and the D&D ruleset into a simpler experience, intertwined with shooter elements. It is, as well, a branching point in character complexity and plot scripting, providing a lot more depth, at the cost of some diversity.

There is so much I want to say of Mass Effect, and so little time to put it into words, that I'll post two separate articles. The first one, this, will focus on the shooter aspects, while the second one will look into the RPG segments and story.

Mass Effect

So, Mass Effect. A shooter developed by a renouned RPG developer constantly trying to make its games more immediate and accessible. Neverwinter Nights felt like a complex Diablo, while Jade Empire was a beat'm up with lots of abilities, few stats and no classes, but still many points to assign. Knights of the Old Republic, however, remained more faithful to their origins, for what I know, in spite of being an action game.
Mass Effect plays a similar trick, becoming a shooter while keeping a lot of its RPG origins: multiple missions, lots of dialog and weapons and a big stats/abilities system. It even goes further than BioWare's previous efforts in world and character design, producing a unique, rich universe with personality. It also gives the player more options than usual in how to play the main story or interact with partners.

If it has so many stats, it has to be an RPG

Living in a shooter

At its heart, Mass Effect is a shooter. No matter how good your character stats are, if you are not skilled at these kind of games, you will have a hard time. But also, no matter how good of a shoot you are, if your character sucks using assault rifles you will not likely hit anything more than 2 metres away. There's a balance between both worlds, and, now, I like that. When I first played, I was expecting a role game, and having to aim pissed me off. I was used to marking targets and having my characters' stats do the work. Once I got used to Mass Effect's real nature, however, things were smoother.

As a shoother, Mass Effect does a good job at reading current patterns in the genre, adapting them and improving where needed. Recharging shields and cover shooting are nowadays almost a must in any slightly strategic shooter, but BioWare's implementation of such mechanics is way better than usual.

Although I greatly dislike the Halo followers which shoehorned shield recharging into any kind of game (World War II was, apparently, won by Wolverine's family), Mass Effect is one of the few that respects the original idea.
The shield is a second chance after a mistake. But rely too heavily on consuming it and your health will be reduced to dangerous levels. The next battle might be too much, if careless. I, as a player, am encouraged to think of intelligent strategies, rather than head on attacks, taking into account that life is a precious, easily drained resource.
U¨nfortunately, the effect is greatly lost due to the wide availability of Medi-gel and, much later, medical interfaces and exoskeletons. It is too easy to recover lost life, a nod, I guess, to the voices crying for easier games. The fact that life recovery are not obtained for free makes things a little better: to keep a constant flow of medi-gels many stats points must go to decryption skills, and using a medical interface means you are not using another armour upgrade. So it is a good rock-paper-scissor system, leaning a bit too much to the forgiving side.

Mass Effect's cover system is also an example of adequate design and integration. The environments include many safe positions, so the player can rest and take careful aim, and using them is simple and fast. The only spot in here is that it is actually hard to actually stop taking cover: the character's resistance to abandon its position is way too high (one second or so), and can sometimes get you in trouble. I must admit, however, that this is possibly a PC specific problem. In consoles, I'd say pulling the analog all the way down will automatically break the cover.
But cover systems are well implemented in most games using them. The ball falls more often in the level design department. In how games have you stormed into an enemy fortress, finding that there are barricades precisely placed so that you can reach the gates without being too exposed? Every time I've seen something similar, my suspension of disbelief just fell down to the floor in tiny fragments, ruining the game. It felt almost like the game designer was standing besides me all the time, pointing at the next safe position.

These boxes are found anywhere around here.

Mass Effect's solution is incredibly elegant: never make the protagonist attack fortresses. All combats take place in natural environments, store rooms, cities and other non-combat specific areas. The fact that there are cover positions in such places is perfectly understundable. Big boxes and rocks lie here and there naturally, fountains and corners, columns or machines. And all is designed to blend with the area, making action sequences feel more natural and less scripted.
Yes, the designer is still there, but the manipulation is now indirect and I have to actively look for it to understand the designer's intentions in a conscious level. Reasonable environments fool the mind into thinking it is finding strategical positions by itself, even if they were craftly designed to give the player the upper hand.

The other innovation to shooters is in the ammo department. Replacing actual ammo with overheating weapons controls fire rate, average damage output and makes self-restrain a necessity to advance in the game. Overheating a weapon incurrs in a considerable penalty: either wait until it cools down completely or use a different weapon, one your character might not be too good with. Once again, a stylish cost-benefit balance.
And the explanation of the infinite ammo and shooting mechanism is actually cool. From Mass Effect's Wikia page: "The guns shave a bullet the size of a grain of sand off a dense block of metal stored in the gun, decrease its mass with a mass effect field, and fire the projectile at supersonic velocities." As a hard sci-fi lover, I must say I love that. And rail-guns are a theoretical beauty.

Conclusions (shooter)

Yep, the sequel is that low.

Mass Effect is a hell of an action game. Although a bit too easy for my taste in normal, it proves quite a challenge. The fact that the challenge is limited to each bullet fight, instead of longer missions or areas, steals part of the fun. The putties' mission was to wear the Power Rangers down; they were never strong enough to kill any of them. But BioWare decided to make every combat a more dangerous experience, I guess. I don't like that, but not enough to substantially change my opinion of the game.
And, even if it is not a shooter at heart, it still does much better as such than pretty much any recent game in the genre has managed to. Only RPG blenders like STALKER or Deus Ex stand by its side.

Review: Beyond Good & Evil (Ubisoft, 2003)

2011-03-05T03:50:00.001+01:00

Platform: PC, GameCube, PS2, Xbox, X360 (XBLA), PS3 (PSN, pending release)
Website: Wikipedia

With the re-release of Beyond Good & Evil on current gen consoles (Xbox 360 and PS3), reviewes of this modern classic have appeared everywhere. Apparently the new version features increased resolution (1080p), improved textures, the dreaded achievements/trophies and, most notably, a revamped soundtrack with some new tracks and better audio quality. The original music was great, but word is the updated version kicks even more ass.
Otherwise, the game remains the same. Same mechanics, art direction, level design and sense of humour. And that's good, because I don't care much about graphics and can review the original while saving the money.

There is no point in repeating what every other site out there has already posted, so I'll focus on what sites have not mentioned so much and, in a form of meta-review, about the reviewes themselves.

About reviewes

Before jumping into the game, I'll make a reference to the reviewes I've read lately about this game. All praise Beyond Good & Evil, of course, being one of the points usually featured its originality: in an industry dominated by copy-cats and sequels, it was an inspiring change, innovating old formulas and exploring new areas, unconstrained by the weight of an intellectual property (partly).
Everyone agrees that re-releasing this game was a no brainier. A great experience, beloved by all the critic, which sold poorly, but can easily pay for itself now. Also, any chance it gets to gather attention is welcome.

However, the very same people that admire its uniqueness always end asking everyone to buy the remake, so a sequel is finally released. What? What about that anti-sequels, pro-originality speech? Forgotten in two paragraphs?
Well, I don't want a sequel to Jade's adventures and I didn't like the cliffhanger ending. I'd love to see Ancel direct new games, not rehashes of old ones, because he's shown he can do great things. Rayman was really good, but by the second installment I was already sick of it. I don't want Jade to suffer at the hands of her very own Raving Rabbids.

No Zelda

The most common word you'll hear when someone describes this game is "Zelda". It is always sold as "a great game every Zelda fan should try," as if its only merit was being good enough to play with the big boys. But few point out that there is a lot more to Jade than its ancestors. As a confessed Zelda non-fan, I must disagree.
I admit there are aspects in common among both games: Jade wears green jacket, belt and lipstick; combat is simple, yet deep; world and dungeons are clearly distinguished; art direction is very controlled. But, for what my opinion is worth, I'd say the cause for those similarities is that Zelda was an inspiration, not that Jade is "Link not done by Nintendo."

The design team, obviously, held Link's adventures as a reference and guiding light. The way things are, most of them would be long time fans of the series, so it is no wonder. But they built Beyond Good & Evil rethinking every aspect from the ground up, instead of blatantly copying the source. When faced with the same challenges any 3D Zelda game ever solved, they tried to come up with new solutions.
In the end, Jade and Link solve similar puzzles with very different approaches. For example, instead of a cluttered inventory, Jade has very few items: a club, a camera and a grappling hook (gyrodisk glove). Every other equipment you'd expect in a Zelda game is merged into Jade's companions, easily accessible with a button, or simply removed. Every frequent action can be performed instantly, never requiring a sub-weapon selection menu.
And, still, Jade can do about everything Link did. This streamlining of the Zelda experience worked wonders for me, as I could now focus on walking around the world, marvelling at the caves and puzzles or looking for animals to photograph.

But a lot more

Beyond Good & Evil has also a lot more going than Zelda. Combat is way faster, almost like beat'm ups, with camera locking only required for special movements; carefully planned infiltration missions reminiscent of Metal Gear Solid 2; and arcade-like vehicle battles and races.
There are also actual characters in this game, which the player cares for, despises or pities, two of them Jade's companions in her battle. Instead of the shallow personalities you can find in Zelda games*, Jade has actually someone to care and long for. And her despair when losing any of them is shared by the player, because they felt way more real than all Zeldas* Link ever rescued.

* Excluding Wind Waker

Conclusion

In the end, Beyond Good & Evil built on the foundations of Zelda, but changed the packaging in so many ways that it surpassed its master. Unfortunately, the first impression when starting a new game is so strong that players are left with a Zelda taste always lingering in their minds.

Anyway, as I stated on my previous Zelda review, I hope the roles are inverted and the next Zelda turns to its alumni for fresh ideas.

Review: Samorost 2 (Amanita Design, 2005)

2011-02-18T01:43:00.011+01:00

Platform: Linux, Windows, Mac (digital distribution), Flash (web browser)

Website: http://amanita-design.net/samorost-2/

Not long ago, and guided by general consensus among friends and critics, I decided to acquire Machinarium, the then recent work by Amanita Design. To my surprise, when buying the game I was given their previous one, Samorost 2 (its first part is free), and both game's soundtracks. Shortly after I refused to keep playing Machinarium (another story) and mostly forgot about Amanita.

Fast forward to a boring evening, when I discovered Samorost 2's installer in my PC. "Let's try this," I told myself (metaphorically; I don't usually talk to myself), "a free game can't be worst than most you pay for."

Amanita Design is a studio specialized, judging by their main games, in Flash development and extremely detailed graphics. Gray, complex landscapes play an important part in their games, as do their beautiful musical scores. These two elements have earned the studio repetead and completely deserved awards.
Amanita's designs are, in essence, point and click graphic adventures with a very simple inventory system, if any, minimal stories, pretty backgrounds and limited interaction.

In Samorost 2, the main character -let's call him/her Pyjama- wakes up to find a couple of space thieves stealing fruits from the garden's tree, and taking the guardian dog as a bonus. As a result, Pyjama embarks on an mission to rescue Dog and return to the home asteroid safe. And the player, not to be confused with the star, goes along for the ride.
Pyjama's adventure is a nice one, full of funny moments, detailed drawings, charming characters and some curious puzzles. So there are good things regarding this game. From time to time my efforts were rewarded with something more than "you managed to cross the door", which felt good, but not good enough. I always had this sour taste of frustration reminding me that I wasn't that much enjoyed.
But critics and players loved this game, so I am outnumbered. Am I wrong or do I have the right to call my Graphic Adventure Demise Culprit #3 to scene?

How does it play?

The game is played with the mouse, interacting with the environment or, sometimes, Pyjama. Whenever the cursor is over an interactive object, it turns into a pointing hand, Myst style. You click and something happens. Maybe it will break, or Pyjama will place some object in its pocket, or an insect will fly away, or the cursor will turn into the selected object.
It is important to note that whatever happens, it is usually not related to Pyjama. The player is an external entity which forces the environment into action.
Most of the time the player toys freely with the environment, other times Pyjama interacts with the selected object, or picks it. Those actions in which Pyjama participates are not marked as interactive unless Pyjama is close by. And to place Pyjama there, you must click in an area where Pyjama might want to stand, turning the whole screen into a potentially interactive area.

So, the first problem appears: pixel hunting is the way to go. And it is even worse because background and interactive area most of the time cannot be told from one another. Everything in the game has decorations, wheels, buttons and levers, but most of them serve no purpose. Even worse, some can only be used if a certain object has been picked by the cursor. Unfortunately, in these cases the cursor loses its ability to notify that an interaction is possible. For a certain puzzle, I had to try placing a bell in each tree branch in a forest until I found the right one, because I had no visual clue regarding what was I trying to achieve. And let me tell you, Amanita loves adding trees and branches to their scenes a little too much.

What's an alien supposed to do?

There are also scenery elements which can only be used when they are in certain positions, which adds an even more frustrating aspect to pixel hunting: timed interactivity. And not everything that moves is at some point interactive. In fact, most moving stuff is just decoration.
This dynamic pixel hunting by itself would be enough to throw this game away. Even though the game is only 90-120 minutes long (10-20 minutes if you know what to do), it managed to frustrate me almost to the point of quitting around five times. I did not, but just because I am very stubborn.

But that is not all, folks. Not knowing what can be used to fulfil your objective is bad enough if you have one, but when the designer's intentions are anything but clear, you are in trouble. Of course, that was the case more often than not.
In video games, as in life, objectives are stacked one over another, according to the order they must be performed to progress.
For instance, in a given screen in Samorost 2:
- Global objective: Rescue the dog.
- Room objective: Reach next room. There is a worker there, so it cannot be done via the door.
- Sub-objective layer 1: Find another exit, I guess. Or something to throw at the worker. FIND SOMETHING!

To find an exit in this puzzle you only have the option of clicking around, because no obvious way out can be seen. I won't spoil the series of events, but it includes turning on an object with no real relationship to the problem , and which you were not even aware was off. You discover it is when you click on a drawn line behind it. You discover why you wanted to turn it on after the fact.

So, we mix a nightmarish environment interaction with unclear objectives and get... a bad, although pretty, graphic adventure, overwhelmed by its abuse of elaborate drawings, with some charming puzzles. And another reason for the average player to stay as far away as possible from the genre.

Conclusion

That middle ground is deceiving...

In the end, as was the case with Machinarium, I found out too late, most people saw the game, thought it was pretty, got a bit into it and quit in frustration at first chance. But players still thought the game was pretty, some how funny and relatively original, so they recommended it all around. In Samorost 2, being way shorter, most people probably finished it and forgot the two hours of frustration it included. Marketing has taught us that the mind remembers beautiful and funny things easier than hard and boring ones.

On OnLive

2011-02-14T14:09:00.000+01:00

By now, every person even slightly interestedn in video-games should know about OnLive. Those who don't, would do well to read a bit on it and its competitors. Those in Nort America might even try it out, if their internet connection allows it.

In brief: OnLive is a remote gaming system. A player can start a game from the service in a not too powerful machine, and play, ideally, as if the computer was a modern monster. The game itself is executed on OnLive's computer cluster, in one of their machines. The player receives a video stream of the screen, and the input is sent back to OnLive to process inside the game. If the internet connection holds up, the experience should remain a close match to playing on your own PC.
The limitations this system imposes are in resolution (the stream is limited to 1280x720), the artifacts caused by the video compression and the time passed since the player sees an image (or hears a sound) and the game receives the player's response.

Then, what is so important about OnLive? It is, obvlously, an industry changing concept. The PC and console markets have been led by power hungry machines, paid for by the players. Now, costs can be sustained by an external party, theoretically reducing the cost of playing the latest and biggest games.
It is also relevant as an innovative distribution method: there is just no distribution. A client pays for the right to play a game. No installation files, disc, activation any more. And no more patching on the player's side. And you can play anywhere, on any PC.
Unfortunately, the games are associated to a single account, so you can no longer share a game with your brother, friend, partner... without sharing the whole account. Unless multi-person accounts are offered, obviously.

For developers, on the other hand, OnLive could imply a console like environment for PC games. OnLives machines can be tested, avoiding the hell of multi-configuration set-ups. And, at the same time, can always aim for the best possible graphics, without taking into account the number of high-end computers in the market. Of course, these points are irrelevant as of now, given the low penetration of OnLive in comparison to world wide PC games sales.

But what are the potential effects of such an environment on the whole industry? In the coming years, as internet connections improve, hardware gets more robust and OnLive and similar companies finetune their core systems, things will start changing. It might not be OnLive, but it is undeniable that someone, some day, will triumph with a similar scheme*.

Trying to predict future market movements is considered by many a great exercise, even if you get everything wrong. So, what are my predictions for gaming, in the light of this technology?

The next generation of home consoles, along with downloadable titles and disc based content, will include a game streaming service. Probably through a partnership with one or more of the OnLives of the future, due to the huge costs of creating such supercomputers and maintaining them. Exactly the same as happened in the 360 and PS3 with NetFlix, Hulu, Mubi and the likes.
The possibility of this happening on portable consoles depends on improvements on wireless connections and international regulations, and will probably be delayed one generation more.
There will be at least three subscription types: play a game forever (30-40€), play the latest games for a month (30€) and play over a year old games for a month (10-15€). Of course, there will be many offers mixing them around, including a complete subscription for everything.
Episodic games will be way more common, and signed to one of the competing services, the same way series are now to specific channels. A new 4-5 hours long episode would be released every one or two months, giving clients a reason to remain loyal to a service. This interests developers, since they can start paying their initial inversion before having the whole game finished, and players, since design flaws (and, of course, bugs) can be fixed as the story progresses. However, developers must meet the datelines, by properly planning everything. Valve would have a serious problem with this.
Valve's Steam will present a competing service in less than 2 years.
10 years from now, disc based games will be gone. This, episodic games and affordable yet powerful engines will considerably reduce the average cost of high profile games development. Most companies will work in at least two games at once, debunking the current trend of placing all hopes in a multi-million project.
Graphics card evolution will significantly slow down 5 years from now, if these systems prevail. The demand for high end graphic systems will be limited to fanatics, OnLive and similars, and console systems. The push from computer gaming top gamers lost, the costs of developing übercards will be unrecoverable in the short term, so there will be less GPU releases per year (less than one, I'd say), and the differences will be much more pronounced than now, to give OnLive a reason to upgrade. NVidia and AMD (its ATI branch) will, however, remain in the market thanks to CUDA and other developments for the scientific community, plus video decoding, in which they have more competitors.
If things remain the same in three, five and ten years I'll be very, very sad.

Let's see how things have worked out 3 years from now!

* The biggest issue will be internet connection caps, if they are still prevalent 3-5 years from now. Playing for an hour could easily consume half a gigabyte of your monthly maximum: 1280x720 means 3 GiB uncompressed video per hour, which could be compressed down to 200 or 300 MiB; one hour of 192kbps in ogg is 80 to 100MiB; plus the input and synchronization info, which can be up to 100MiB, too.

Review: The Legend of Zelda series

2011-02-08T19:10:00.000+01:00

Link: one of the longest lasting and most beloved icons in the interactive media world. An almost eternal boy, constantly saving the world at the last moment from Ganondorf's evil schemes, in which Princess Zelda is always involved, to a varying extent. Most often, she is the recipient of some form of legendary power and the key to controlling the ~~TriState Area~~ Triforce.

We've heard this story six times already (counting only Nintendo home console versions), with different variations. However, in terms of gameplay, evolution was limited to the first four games. Zelda II was a significant departure from the original, Super Zelda improved Zelda's top-down exploration almost to perfection, and Zelda 64 changed the way 3D adventure games were built. However, from Zelda 64 on, little has changed. Each game in the series would get its defining characteristic/mechanic, but general story, controls, menus or items remained pretty much the same.

Late Beginnings

I love A Link to the Past as much as anyone, even though I never finished it. It had good puzzles, tricky dungeons and awesome dungeon bosses. What made boss fights so good was the fact that they were difficult, until you learnt the method. After attacking the enemy three or four times, each with a little higher difficulty, the game acknowledged you as the winner. No five minutes battles, no constant die and retry, no rinse and repeat. This, for me, is the defining mark in the Zelda genre, and its greatest gift to computer game design. It is recognizable in every Zelda game afterwards, but also in the Metroid saga, Soul Reaver or Beyond Good & Evil.

The Light World

In other aspects, the game always felt quick, even when you were stuck. The moment you entered a room you easily identified every relevant item in seconds. Killed some minions, activated a switch and moved to the next area. Opened a chest, saw a 2 seconds description and moved on. Killed a boss, collected a heart and an object, got out of the dungeon in seconds and moved on. Every action was snappy and the game was constantly pushing you forward, with short conversations and a very streamlined interface.

Basically, Super Zelda kept the obstacles between the player and the actual Hyrulean struggle to a minimum.

Evolution comes at a cost

Seven years later came The Legend of Zelda: Ocarina of Time. Three dimensions opened many new opportunities and challenges and Ocarina of Time was the first game to find an appropriate balance between camera freedom and combat precision. Its lock mechanism proved to be a very effective solution, finding its way into almost every three dimensional adventure game, plus the Metroid Prime series.

Lock-on or Z-Targeting in Ocarina of Time

But disregard the graphics and camera management, and you will find Super Zelda all around. Same platforming mechanism, multi-menu system, main and secondary weapons, dungeon schemes and items or contextual buttons. Some new aspects were introduced, like ocarina playing (precursor to Guitar Hero?) or adapted to the new console, like the new C-pad sub-weapon management. But the immediacy of the 2D Zelda was lost: the number of times you have to change sub-weapons is reduced, but, each time, you face a slow menu and a button re-mapping. The experience became one in which the player makes a great effort to reduce the need to enter the menu to a minimum. The snappiness of exploration was also lost: in Ocarina of Time a player will spend half of the total play time looking around, identifying interactive objects, aiming and opening chests. All of these actions are slow to perform, almost to desperation. The chest opening sequence is specially guilty. It lasts at least 10 seconds, and every time you pick an object it is described. To make things worse, the chest opening music is the same it always was, so it ends way before the text dissapears.

Unfortunately, this became Zelda 64's legacy: zero menu agility and constant pauses to aim, change equipment or talk to patronizing NPCs.

Puzzles, as well as in Super Zelda, are repetitive in each dungeon, but are now encumbered by the slow aiming and menu systems. Particularly dreadful in Ocarina of Time and the following Zelda games is the grappling hook. Shooting it a hundred times per temple is so boring that I cannot help but wonder why wouldn't the design team devise some faster or automated way to perform an equivalent action. My best guess is that it was on purpose: increasing play time through repetition was an important aspect in the game design.

Stalled ideas

The following games, Wind Waker and Twilight Princess, kept all the crippling features, only adding some new mechanics and items.

Unbelievably, wind changing and sailing were even worse than usual, forcing the player to play a tune almost every time the boat needed to head in another direction. A single button for hoisting the sail, and one of the analogs to direct wind would have improved the situation greatly. It is sadly telling that the biggest change Wind Waker introduced in the series was the boomerang, which added little to the bow and clawshot and could have replaced both easily. It didn't, so the number of sub-weapon changes required to end the game was increased for no good reason.

Instead of streamlining items, reducing their count, the team preferred focusing on adding new items with one defining ability, even if secondary ones were duplicated. Through the years, Zelda has become the clearest example of feature creep in a series. Nintendo's inability to reconsider legacy designs is disheartening.

And as in Zelda 64, the adventure consisted of forty hours of travels executing irritatingly repetitive, menial, long tasks, solving over-simplified puzzles and generally not having much fun. Too often, the reward is only in finishing the mission at hand, but not in the execution, nor its overall relevance.

On the other hand, Twilight Princess at least had the decency to make shape-shifting, a very common action during the story, accessible with just two button presses. However, after Symphony of the Night, more than one button for such a usual operation seems prehistoric. The rest remained pretty much unchanged.

Midna riding wolf Link

Regarding character design, the other important aspect of Wind Waker was the radical revision of Zelda. Historically a Peach-style princess, barely able to do more than being a kidnapper's easiest target, Wind Waker's Zelda was a stronger character than Link himself. That is not hard, sure, but the designers excelled at creating an interesting female character. Until she was turned into an actual princess and suddenly rendered helpless, useless and pitiable. Wind Waker also introduced a dose of humour and tenderness that made its shortcomings less aggravating.


Tetra, Zelda's incarnation in Wind Waker and Phantom Hourglass

Twilight Princess, of course, introduced little change. Strong-Zelda was replaced with Midna, a relatively funny companion, bringing back the old, weak Princess.

And what about the Future?

Complains regarding the repetitive nature of the series have been heard often lately. Many fans like things as they are now, but there are more people who want the innovative Nintendo to return. Unfortunately, Nintendo has been happily recycling proved concepts since the Nintendo 64 era, only adding little touches of polish here and there, plus one or two new ideas per game. This design principle ensures high quality results and huge doses of nostalgia, but sacrifices creativity and surprise. Every 3D Mario and Zelda plays pretty much the same, with pretty much the same concepts.

To break the bubble Zelda has been living in for the last decade, Nintendo would have to look around and study its pupils. In my opinion, Soul Reaver nailed almost every design choice, but it is not the only one to have surpassed the master.

Only by accepting the shortcomings in Zelda games and looking for acceptable solutions will Nintendo get me interested in the series again. Aonuma promised to apply all his effort in rejuvenating the franchise, but after two major attempts little hope is left. Only the portable versions of Zelda have tried new approaches, but still failed at bringing down the chains linking them to their now 20 and 12 years old ancestors. And in a blooming industry, 12 years encompass 3 different generations of hardware, a couple genres birth and death and an infinite number of paradigm shifts.

Conclusion

After the first two games for the NES, which I chose to elide, A Link to the Past was a step in the right direction, establishing a reference for 2D adventure gaming. Ocarina of Time made 3D navigation and combat look easy, but covered that fluid experience with crippling interfaces and cutscenes. Afterwards, any hope of seeing something new come out of the franchise vanished. Link changed his clothing to great effect, but his heart and guts were just the same.

Meanwhile, adventure games have trodden new grounds for 10 years. No matter how young Link seems to be, he is relic of times past, refusing to let a new breed take control over.

Not a great fan of the series, am I?

Global Game Jamming!

2011-01-31T02:13:00.001+01:00

This weekend (28-30 January) I've participated in the Global Game Jam, the largest 48 hours game dev jam so far. It's been awesome, frustrating, funny, tiresome, stressing and a bit unhealthy. But I survived the ordeal and came out with a finished game, which I still find amazing.

Technology and engines have advanced so much and become so cheap (free as in "free beer"?) in the later years that it is possible to do quite a lot in very little time. This has increased the number of people willing to take part in such events, as well as the average know-how. The most beloved dev platforms seem to be Unity 3D and XNA. I was expecting some Unreal Engine projects, but none surfaced at my location. There were also no iPhone, Windows Phone 7 or Android, so Flash, Java and self-developed engines filled the minority ranks.

The game I worked in is No Ground Left, developed by a small team of two programmers and an artist. Since it was created in Unity, we have Windows and MacOS binaries (tested in Windows 7 and MacOS X). The complete package, including sources, is available from the previous link.
We also have a browser version of the game hosted on GGJ's servers. It has not been extensively tested and content streaming seems to cause some troubles, so you might prefer to try the full application. Also, Unity's Web Player is not as stable as I'd desire.
However, the web version, which was uploaded some hours later, includes an important bugfix and some menu improvements, so it is closer to a good version of the game.

Everything developed during the Global Game Jam 2011 is released under the Creative Commons Attribution-NonCommercial-ShareAlike license, so everyone is free to pick our game sources, change them significatively and distribute the results (for non-commercial purposes), as long as we are credited as the original authors.
I took advantadge of this license to include some professional music in the game. Especifically, I used three slightly and quickly modified cuts of Nine Inch Nail's The four of us are dying for the ambient music. Trent Reznor released that track's album, The Slip, with the exact same license GGJ required us to use, so everything fit perfectly.

Game Design Challenge: Time for Change (part 2)

2011-01-28T01:09:00.001+01:00

And this was my second proposal for the gender altering challenge. It was just an idea I found funny, so don't take it too seriously.
I would have loved to send another one, this time changing Gabriel Knight's assistant Grace Nakimura into a sophisticated adult man. He would have served as a balance for Gabriel's untidiness, and I was considering whether to present him as a sexual rival or partner. Or both. But alas! I didn't have the time to think it properly and compose the text. A shame.

But here you have Canabalte!

Canabalte

The moment you heard of the robot invasion in the Capital, you knew your little Canabalt would leave his apartment with the first clothes he found and without brushing his teeth. That's not the way men should run around, even when the world as we know it is collapsing. So, you have taken your car and driven as fast as possible from the suburbs to the outer limits of the Capital. From here on, you'll have to run and jump to reach Canabalr's apartment before he leaves.

To make it clear you are entering the city, Canabalte runs from right to left, and the distance meter, instead of constantly increasing, will decrease. The distance you have to travel will be the longest distance scored in the Canabalt iPhone version scoreboards. That is, as far as we know, the distance from Canabalt's city to salvation (plus a meaningless amount).
In your way into the heart of civilazation you will find other people running over the rooftops, which will, if you pass close enough to them, give you valuable information about the area they have just crossed. This will be represented by ~~the camera moving to the left~~ zooming out the camera, so Canabalte is on the far right of the screen, giving you more time to calculate your actions.
Once you find Canabalt and ensure he is properly dressed for the escape, your mission is finished and the original Canabalt starts, but now you can see Mom running behind the main character and mimmicing his moves.

Game Design Challenge: Time for Change (part 1)

2011-01-17T17:37:00.001+01:00

I loved the concept of changing a game by shifting the main character gender, so for this particular challenge I sent a couple of ideas; one serious, the other not so much.
The first of them, Princess of Persia made it to the second place, in a draw with another Prince of Persia re-imagining. Although I don't like Shin's display of the female character, I have to admit that his/her game is quite a funny take on Ubisoft's 2008 reboot of the franchise.

Some time after the results were published, I found a forum of female gamers/game designers in which they discussed the finalists*. I would have loved to get something from there, mainly because they criticized my Princess. Unfortunately, I got the impression that most of the critics barely read the first two paragraphs.
However, their point that women are not that much interested in the archetype hero journey made me wonder. In the end, and judging from best-selling books, movies and classics, I think women do connect with the archetype about as much as men, but from a different perspective. But this is another story which shall be told in another moment.

* Being the pile of shit google search is starting to be, I am unable to find it again. If someone stumbles upon it, notify me in the comments and I'll gladly update the post.

Princess of Persia

After 30 minutes, only two choices remain: marry the Vizier to save your lover's life or after his execution. Your last hope for rescue dead, you call the Vizier to submit, but suddenly realize it is up to you to save yourself. The Vizier grinning in front of you, you slowly manipulate your braid, look him in the eyes and smile when your small dagger rips the vermin's chest. After seething it back in your braid, you leave your royal chambers, with one half of the sand silently waiting to reach the bottom of the clock.

"Marry me... or he will die within the hour."

From here on, the princess will have to find her way down to the cells, the path guarded by mostly unkind soldiers. The few guards still loyal to her will be useful in such confrontations, keeping her enemies busy while she progresses. But she soon runs out of allies; the more traps, abysses and thorns overcome, the less royal her dress will look. The princess will finally resort to stripping a corpse off its robes, making all enemies suspicious at first sight. The moment this happens is a function of the princess deaths, close calls avoiding traps, jumps performed and hits received.
But even when dressed as a soldier, the princess can still use sedduction as a weapon, as lonely soldiers can be lured and silently killed with the dagger. Carrying a sword is not an option, since she never received proper training.
As she progress, her sedduction will be less useful, most guards being violent thugs, identified by their rugged clothes, inmune to her charms. The only way to pass them is finding an alternative route or defeating them in combat, when the princess' flexibility and agility can be used to her advantadge. When in combat, the arrow keys make the princess perform acrobatic jumps, rolls or dashes to dodge attacks and, once she is at touch distance, execute a deadly stab with her hidden dagger. Bigger enemies will be harder to dodge and can withstand more than one dagger wound.

After freeing her lover, both will flee from the castle (Prince of Persia 2 opening style) and reach the square before the gates. There, the prince is hit by a poisoned arrow and the princess confronts the Old Man of the Mountain**, who explains her lover is but one of his trainees, convinced to be the hier to the Persian throne and forced to rescue her as a final test. After saving the princess, she'd be killed and he convinced of having reached Heaven, becoming one of the Hashashins.
In her final battle the princess has to defeat her lover, who believes he is commanded by Allah, and the Old Man.

In the sequels, the princess would wander through Asia and Europe, looking for the source of all warrior female tribe myths, including the Valkiryes, the Amazons and the supposedly dissapeared Iceni, descendants of Boudicca.

** Involuntarily, I might have merged Hassan-i Sabbah and Rashid ad-Din Sinan's lifes. Both commanded the Hashashins and the legends of the their training probably had both as responsible at one time or another. I mostly took as inspiration a short story whose writer I cannot remember. Borges? Bukowski? Ecco?

Graphic adventures demise rant

2011-01-12T17:02:00.002+01:00

Before I start posting reviewes of graphic adventures, I find myself forced to write a state of the art, plus my opinion on the genre's slow death. Please, indulge me.

As you should know, in the 80s and early 90s, adventure games reigned supreme in the world of videogames. Their narrative had no equal, as did their ability to treat serious subjects and make people ponder about them. But, as the century approached its end, the genre lost its following and energy.
It is a recognized sport among adventure fans to look for culprits of this decline, and everyone has their favourite. I like to blame:

The lack of evolution in the genre.
The inability to properly embrace the new technologies and platforms (partially related to #1).
The resignation of players and critics, who in the end welcomed almost any new graphic adventure, without regards to actual quality, sinking the standard for the genre and scaring new players away.

Graphic adventures were built from three basic tasks: pick object (or person), use object (or person) and talk to person (or object), all of them poorly executed for decades. Pixel hunting, objects indistinguisible from the scenary, endless conversations of no interest to game progression, cumbersome inventory systems and outdated movement mechanisms were the rule.
From time to time, a developer would discover a way to improve one of these (Alone in the Dark hybridation, Myst's lack of inventory, Gabriel Knight 3's navigation), and implement it in a succesful game. But other designers would rarely include other's ideas into their new game. Copying was not well regarded and, if it were, modifying the engine a studio had used for several titles was not that easy and/or economically viable.

But this blaming is of little relevance in the real world. What is important is not answering "why did graphic adventures dissappear", but "why did most gamers not care at all". You see, people still bought games, even bad ones, by the millions, but adventures only got a waning portion of that cake, no matter how good or praised they were. How can you explain that?
What had made graphic adventures shine over other genres was a mix of their depth in story, characters and humour. Another feature was their relative simplicity, when compared to space shooters, platformers, etc. Anyone with minimum computer expertise could pick up a graphic adventure and click around the screen, select verbs, objects, people and laugh for a while. Puzzles also were part of the magic formula: solving them felt great, and telling your friends when they were stuck was even better.

But these advantadges slowly faded away via the magic of genre merging. Story telling in other genres was improving, so they could talk about something apart from alien invasions, or about alien invasions with actual characters and plot (well, not that often). And there were also puzzles all around; usually the simplest possible puzzles, just fetch quests or box pushing, but that was what most graphic adventures were about, in the end. Controls also went through a standardization process, so more people were able to play the latest shooter without reading a 50 pages manual.
To this point, graphic adventures should still stand the fight in equal terms, right? So all games had simple puzzles and some kind of story; the other genres's action was compensated with graphic adventures' deeper stories and rewarding puzzles. What kept them behind?
There was, unfortunately, another thing adventures did that most other genres did not dare to: annoy players to no end with weird puzzles, which stopped all progress until the solution was found. One single puzzle of this nature would make a huge percentage of the players leave the game and the genre after 30 minutes of desperation. The joys of achieving something were simply not worth that much effort, even more when a similar feeling could be obtained in easier games.
Of course, this has ended being a problem too in other genres, as their fandom developed and games started targeting only that population. Operation Flashpoint, for example, was too much for most shooter fans. But Flashpoint was a niche inside the so-called FPS family; there were nicer or easier options out there. But graphic adventures, after decades of limited evolution, were done by and for the hardcore fans, automatically alienating anyone who did not know and accept the rules.

Thus, players looked for their puzzle solving joys in games which actually provided them. They avoided a great deal of frustration, sacrificing some depth, but adding strategy, action or whatever. Only the most stubborn remained, and although some steps were taken to stop the leak, the graphic adventure boat still sunk slowly.

There are signs of recovery, however, coming from independent and old school developers, which I hope will bring the genre back to a respectable position. But developers, reviewers and gamers must make sure they keep a quality threshold below which noone goes. The only way the genre will remain viable is by getting new players into good graphic adventures.