Lets start with a reply to the original article. Some while after the article was published on .simplicity Valentin Anastase from the non-profit organization Freezing Moon replied. He provided a link to two sites, including Freezing Moon’s, dedicated to free gaming. Freezing Moon comes close to the idea that I sketched in the previous article, but it is not completely the same. Opposed to the Free Gaming Alliance, Freezing Moon actually develops games themselves. While I think that we should first deal with other issues concerning free gaming, I am happy to see an initiative like Freezing Moon and I encourage people to check it out.

Another interesting development can be found at OpenGameArt.org. OpenGameArt.org is a website that hosts “free, legal art for open source game projects”. It started small, but the amount of art has been growing fast. And the art that is being hosted on OpenGameArt.org is certainly not bad; it looks very good. If you are looking for art for your Free Open Source Game or want to support free game art (OpenGameArt.org accepts donations), then definitely check OpenGameArt.org.

So, there are initiatives focused on Free Open Source Gaming, but what about me? Through Sirrf I am trying to improve the Free Open Source Gaming ecosystem. I am wondering if I can have an impact on it in other ways, though.

Sorry for the long time no update, hope you are still watching.

Some small updates after the break.

Medievil

The first game I decided to play on the emulator. It was decent fun, but the best part was really in the story. It’s not the depth, but it’s the humor. The green gargoyles keep mocking you in really funny ways and the text is just top notch. Medievil’s story telling is for games what Shakespeare’s was for drama, a thing to strive for.You play Sir Daniel Fortesque who is a hero from long long ago. He battled his way to the evil sorcerer Zarok’s castle and with his dying breath he killed Zarok. At least, that what’s the books say. What really happened? Get the game, I don’t want to spoil that for you. But keep in mind that this is a really funny game. Anyhow, several decades or so later you wake up from the dead because Zarok is at it again and it is up to you to stop the evil sorcerer.

The sound was good! Almost every level has it’s own theme and they all fit, plus the voice acting! I like it a lot. In the Hall Of Heroes, a bonus-shopping level, each hero has it’s own accent and funny lines. Good stuff.

The gameplay was decent. Replay value is none, which makes it a short game. My first and only run through the game took me 5 hours. Some annoying things are the jumps: Fortesque can’t jump that good and you fall to your death way too often. It’s frustrating, it adds unnecessary repetition to the game. The fighting is more button bashing (or when you have a turbo-button like me, button holding) than strategicly doing stuff. You run, you charge your special attack, you kill the monsters. None of the monsters are a real threat which in the end makes this play more like a platformer and since Sir Dan sucks at jumping and steering him while running isn’t with the accuracy of a modern day FPS the game doesn’t score high on gameplay. The game has some wicked weapons and even a shield system which is easy to master and use, but you’ll never find yourself using it because you’re invincible as long as you keep hitting attack. It’s a shame really, the fighting could have made this game a lot more special and fun.

In the end:

+Good story!
+Good sound!
+Lots of humor

-Plays like a platformer, and not a very fun one.
-No replay value, short playthrough, combined making it a short game.

Medievil’s good sides make up for the suckier parts. Medievil is definitely worth a look: 6 points.

Stay tuned for when I finish my next game!

• Script-side GameStates
  It is now truely possible to derive from the GameState class (through CGameState) in scripts. A bug in previous versions prevented this, but this bug has now been fixed.
• Script-side Components
  EntityComponent can be derived from script-side (through CEntityComponent), classes in script can now create components and register them with entities from script or engine side.
• Script-side Events
  The event system is now integrated into the script engine. Script-side classes can derive from IHasSlots and can register, connect and disconnect from slot events.
• Important Bug Fixes:
  • Construction of entity components with parent is now relatively safe. If you are not sure whether your component has a parent, check it after construction. If the component has no parent, destroy it as quickly as possible
  • AssetProcessors on windows were never loading assets unless the files were all lowercase, restrictions were irrlicht related but solved.
  • Minor bug fixes with script side things, Scolor fixes, asset groups on entities and much much more.

Useful links
SourceForge.net page – http://sourceforge.net/projects/sirrf
Downloads – http://sourceforge.net/projects/sirrf/files/ | http://www.ohloh.net/p/sirrf/download?package=Sirrf
Documentation – API | Tutorials

• Asset Management
  The biggest new feature is asset management. Assets are managed by the AssetManager class. This manager manages so-called asset groups, which represent a collection of assets (meshes, textures, etc). These assets are retrieved from a directory with the appropriate directory structure. In turn the found assets are processed by asset processors. And at the end of the road, the user can use these assets without having to deal with paths. Furthermore asset management makes it possible to reload all assets in realtime, with direct results on the current scene. Reloading assets is as simple as one function call.
• XML-based Entity files
  It is now possible to load data concerning entities and their components from XML-files. This means that you can now define a scene through XML-files.
• Local Event System
  As of version 0.2.0 a HasEvents class, which provides the base for a local event system, is available. The availability of local event systems makes the entire framework more performant. Currently the HasEvents class is used by entities and asset groups.
• Microsoft Visual C++ 2008 support
  Version 0.2.0 is the first release that officialy supports Microsoft Visual C++ 2008. This should make it easier to set up Sirrf-based projects accros multiple platforms.

See the change log for more information regarding the changes in Sirrf version 0.2.0.

This is not the end of Sirrf’s development, though. Sirrf’s development will continue and Sirrf will undoubtely become even better in the future. And you, as a Sirrf user, as a member of the Irrlicht community, can help us improve the framework. This can be done by contributing code to the project, but also by testing the framework. Either way, we hope that Sirrf will be of use.

Useful links
SourceForge.net page – http://sourceforge.net/projects/sirrf
Downloads – http://sourceforge.net/projects/sirrf/files/ | http://www.ohloh.net/p/sirrf/download?package=Sirrf

Introduction to the Alliance

Games are a complicated beast. A Free Gaming Alliance could help free games during those steps that are crucial to making a successful game: organization, development and publication. And during all steps the goal of the alliance would be the same: to provide professional help to free games. Taking over projects should not be a first thought. Consultants of the alliance would work as external members of the development team. It is not completely unimaginable, though, that the alliance would take over a promising project with the consent of the development team. That way the alliance could allocate more people and money to the project. But again, this should not be the case with every project. Besides there would be also be cases funding would be possible without a project takeover.

Organization

In terms of organization the Free Gaming Alliance could help projects with finding a team. When it comes to the programming department, free games have few problems. However, when it comes to content creation there are more problems. If you have ever visited an amateur game development website you might have noticed that there are few artists (designers, modellers, composers, etc) in comparison to programmers. The solution would be quite simple, though. The alliance could host a website where artists and anybody else involved in game development could upload free content (models, music, pieces of code, etc). At the first place projects in development projects could get the content they need. And secondly anybody involved into free game development would have a place to show of their skills.
Furthermore the alliance could also advice projects on topics such as deadlines and anything else related to organization.

Development

With regard to development the Free Gaming Alliance would have a simple job. The general FOSS community has already produced various tools which can be used for game development: GIMP and Blender to name two. Also with regard to SDKs there are already many usable products. These SDKs range from low-level (OpenGL, OpenAL, etc) to high-level (Irrlicht, Ogre, CrystalSpace, Horde3d). But tools are only one (important) part of game development. Another part is the development of the game itself. This is something the project team will be responsible for them self, but the alliance could advice and actually commit content. Furthermore it is not completely unimaginable that the alliance would create their own tools, libraries and maybe even platforms for game development.

Publication

And last but not least: publication. There are already various hosts for FOSS: SourceForge.net, Google Code, Ohloh. However, these hosts are not game specific. It is quite possible that this scares potential gamers. The Free Gaming Alliance could fill in this gap. By doing this the alliance could also offer services to monetize on publication. These services could include marketing, merchandise, package publishing, etc. Of course this would not only benefit the alliance, but also the project (shared revenue).

Conclusion

Yet, the Free Gaming Alliance is still a dream. I would love to see a real-life implementation, but I realize that it would be quite an undertaking. Still, it is an interesting and I would not mind working for such alliance.

Useful links
SourceForge.net page – http://sourceforge.net/projects/sirrf
Downloads – http://sourceforge.net/project/showfiles.php?group_id=260711 | http://www.ohloh.net/p/sirrf/download?package=Sirrf

But what can Sirrf do for you? In it’s current state Sirrf offers game logic, graphics, scripting and sound control. Some noticeable features are:

• Data Store
  The Data Store allows you to store primitive value types such as integers, floats and doubles in a type-independent format. These variables can be accessed from anywhere within the framework, from both native and interpreted code, through the DataStore and DataStack classes.
• Entity Management
  In Sirrf entities are component-oriented. The idea behind Component Oriented Entities is to make entities data-driven. In order to do this the functionalities are split in various individual components. As a result an entity is in fact nothing more than a collection of components. So, what an entity represents, is defined by its components. Sirrf currently offers various components in the fields of graphics and sound. Furthermore Sirrf also provides an Entity Manager which should be seen as the central interface point to all entity related issues.
• Event Management
  Sirrf’s event management is build upon sigslot. This means that Sirrf follows an observer model where objects have to subscribe to an event if they want to react to that event. Currently observers can subscribe to game logic events, input events (passed from Irrlicht) and GUI events (again, passed from Irrlicht).
• Game Management
  The Game Manager performs generic game initialization and deinitialization. It also provides functions to access sub-systems of the framework, such as the Event Manager and the Entity Manager. It’s main function, though, is to control the flow of the game through game state management. This class provides various features to this end.
• Scripting
  Sirrf is almost completely accessible through AngelScript, a free and open source scripting language. AngelScript allows users to extend applications on run-time using scripts that follow a C/C++ like syntax. Furthermore it’s easy to extend Sirrf’s AngelScript bindings even further.

You might be wondering, though, if Sirrf is really something for you. It’s obvious that Sirrf is ideal for newcomers to Irrlicht and game development, but Sirrf should also be useful for experts. Especially now experts are more than welcome as Sirrf is still in beta status.

In the coming time focus will lie primarily at adding additional documentation. This will be an crucial step to make the framework more accessible to newcomers. And of course Sirrf will also be extended with new features.

Useful links
Development Hub – http://sourceforge.net/projects/sirrf
Downloads – https://sourceforge.net/project/showfiles.php?group_id=260711

The Sirrf Project

Project name

Sirrf – Simple Irrlicht Framework

Brief description

Sirrf, the Simple Irrlicht Framework, is an extensive, but open source and simple framework for rapid game development. Sirrf provides end-users a game skeleton which implements concepts such as states, component-based entities and a datastore. Newer hobbyist game developers will probably benefit most from the project, but hopefully Sirrf will also be useful for experienced developers.

Target aim

Long term

Making a game isn’t a simple task. The goal of the Sirrf project is to create an extensive, but simple framework to enable rapid game development. Furthermore, Sirrf is aimed for as broad of a target audience as possible. Sirrf hopes to accomplish this by maintaining a cross-platform nature and a lack of genre specialization. Additionally, the framework is not-for-profit and open source, licensed under the zlib/libpng license.

Short term

At the moment the main priority is to finish the core, which will form the base for future releases. The first release is expected after Irrlicht 1.6 and AngelScript 2.17.0 are released.

Compensation

Sirrf is open to donations, but this doesn’t guarantee regular financial compensation. So expect to work largely without financial compensation.

Technology

There are no requirements for developers to use specific tools; developers are free to choose their own tools. Please note that Sirrf currently uses the following languages and APIs:

Programming Language: C++
Scripting Language: AngelScript
Rendering: Irrlicht
Sound: SFML-Audio

Talent needed

C++ Programmers

Sirrf is looking for additional programmers. Moderate knowledge of C++ is required. Knowledge of other components, such as AngelScript and Irrlicht, is preferred. You’ll work with other programmers over the SVN of Sirrf. As programmer you’ll be working on multiple different areas of the code, but it’s possible to specialize on one part of the code. Additional programmers on the following topics would be much appreciated:

- Core Development (graphics, scripting, I/O)
- Physics

Windows and Mac OSX Maintainers

Sirrf is currently only supported on Linux; maintainers for Windows and Mac OSX are needed.

Team structure

Michael Bartsch

In the past I’ve worked on several projects. The smaller projects nearly always involved some implementation of Irrlicht. My bigger projects, however, are mostly unrelated to Irrlicht. My latest project was the Aia-project, a project with the goal to create a small artificial intelligent robot. And before that I worked on Entwined Worlds, a 2D Action-RPG, that has never been released. Furthermore, I’m one of the editors of .simplicity.

Contact Information

Contact me via SourceForge.

Additional Information

Links

Development Hub – http://apps.sourceforge.net/trac/sirrf/
SourceForge Project Page – http://sf.net/projects/sirrf/
Subversion Repository – http://sirrf.svn.sourceforge.net/viewvc/sirrf/

The idea behind Component Oriented Entities is to make entities data-driven. In order to do this the functionalities are split in various individual components. As a result an entity is in fact nothing more than a collection of components. An added advantage is the ability to describe these components (and thus the entities) in XML or a similar mark-up language.

Yesterday I actually had a discussion with Nick about Component Oriented Entities. Initially he disagreed with me as I had some trouble explaining the “dangers” of the blob anti-pattern (a huge single class with a large amount of complex functionality). Later on, he agreed with me, but he also pointed out some things to keep in mind. One of those things was the implementation. And I really agree with that as these kind of things stand or fall based upon the implementation. Which brings me to my own implementation of Component Oriented Entities. Please note that all of the following code has been placed in the public domain and that I’ll take no responsibility or liability of any kind for any use that you may make of this code.

Lets start with the Entity Manager.

EntityManager.h

#ifndef __ENTITYMANAGER_H__
#define __ENTITYMANAGER_H__

// Include files
#include "../dependencies.h"
#include "Entity.h"

// Forward declarations
class Entity;

// EntityManager class
class EntityManager
{
public:

    // Initialisation and deinitialisation
    EntityManager();
    ~EntityManager();

    void init();
    void clear();

    // Methods
    bool addEntity(Entity *entity);
    Entity* createEntity(const std::string &name);

    Entity* getEntity(const unsigned int id);
    Entity* getEntity(const std::string &name);

    void removeAll();
    bool removeEntity(Entity *entity);
    bool removeEntity(const unsigned int id);
    bool removeEntity(const std::string &name);

private:

    vector<Entity*> mEntities;
};

#endif

EntityManager.cpp

// Include files
#include "EntityManager.h"

// EntityManager class
// EntityManager constructor.
EntityManager::EntityManager()
{
    init();
}

// EntityManager deconstructor.
EntityManager::~EntityManager()
{
    clear();
}

// Initialises the Entity Manager.
void EntityManager::init()
{
}

// Clears the Entity Manager.
void EntityManager::clear()
{
    // Clear entities.
    removeAll();
}

// Adds an entity to the Entity Manager.
bool EntityManager::addEntity(Entity *entity)
{
    // Did we get a valid pointer?
    if(entity == NULL)
      return false;

    // Look if a entity with given name doesn't already exist.
    if(getEntity(entity->getName()))
      return false;

    // Add the entity.
    mEntities.push_back(entity);

    return true;
}

// Creates an entity with the given name and adds it to the Entity Manager.
Entity* EntityManager::createEntity(const std::string &name)
{
    // Look if a entity with given name doesn't already exist.
    if(getEntity(name))
      return NULL;

    // Add the entity.
    Entity *entity = new Entity(name);
    mEntities.push_back(entity);

    return entity;
}

// Gets the entity with the given ID.
Entity* EntityManager::getEntity(const unsigned int id)
{
    for(unsigned int i = 0; i < mEntities.size(); i++)
    {
       if(mEntities[i]->getID() == id)
         return mEntities[i];
    }

    return NULL;
}

// Gets the entity with the given name.
Entity* EntityManager::getEntity(const std::string &name)
{
    for(unsigned int i = 0; i < mEntities.size(); i++)
    {
       if(mEntities[i]->getName() == name)
         return mEntities[i];
    }

    return NULL;
}

// Removes all entities.
void EntityManager::removeAll()
{
    for(unsigned int i = 0; i < mEntities.size(); i++)
      delete mEntities[i];

    mEntities.clear();
}

// Removes the given entity.
bool EntityManager::removeEntity(Entity *entity)
{
    // Did we get a valid pointer?
    if(entity == NULL)
      return false;

    // Try to remove the entity.
    vector<Entity*>::iterator it;

    for(it = mEntities.begin(); it < mEntities.end(); it++)
    {
        Entity *ent = *it;

        if(ent == entity)
        {
           delete ent;
           mEntities.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// Removes the entity with the given ID.
bool EntityManager::removeEntity(const unsigned int id)
{
    // Try to remove the entity.
    vector<Entity*>::iterator it;

    for(it = mEntities.begin(); it < mEntities.end(); it++)
    {
        Entity *ent = *it;

        if(ent->getID() == id)
        {
           delete ent;
           mEntities.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// Removes the entity with the given name.
bool EntityManager::removeEntity(const std::string &name)
{
    // Try to remove the entity.
    vector<Entity*>::iterator it;

    for(it = mEntities.begin(); it < mEntities.end(); it++)
    {
        Entity *ent = *it;

        if(ent->getName() == name)
        {
           delete ent;
           mEntities.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// End of File

The Entity Manager takes care of organizing all entities. Through the Entity Manager it’s possible to create, add, get and remove entities. To this end the Entity Manager offers various methods.

Now lets look at the Entity class.

Entity.h

#ifndef __ENTITY_H__
#define __ENTITY_H__

// Include files
#include "../dependencies.h"
#include "EntityComponent.h"

// Forward declarations
class EntityComponent;

// Entity class
class Entity
{
public:

    // Initialisation and deinitialisation
    Entity(const std::string &name);
    ~Entity();

    void init();
    void clear();

    // Methods
    unsigned int getID() const;
    const std::string& getName() const;

    bool addComponent(EntityComponent* component);

    EntityComponent* getComponent(const unsigned int id);
    EntityComponent* getComponent(const std::string &name);

    void removeAll();
    bool removeComponent(EntityComponent *component);
    bool removeComponent(const unsigned int id);
    bool removeComponent(const std::string &name);

private:

    // Static members
    static unsigned int mIDCount;

    // Normal members
    unsigned int mID;
    std::string mName;

    vector<EntityComponent*> mComponents;
};

#endif

Entity.cpp

// Include files
#include "Entity.h"

// Entity class
// Static variables.
unsigned int Entity::mIDCount = 0;

// Entity constructor.
Entity::Entity(const std::string &name)
: mName(name)
{
    mID = mIDCount++;

    init();
}

// Entity deconstructor.
Entity::~Entity()
{
    clear();
}

// Initialises the entity.
void Entity::init()
{
}

// Clears the entity.
void Entity::clear()
{
    // Remove all components.
    removeAll();
}

// Gets the ID of this entity.
unsigned int Entity::getID() const
{
    return mID;
}

// Gets the name of this entity.
const std::string& Entity::getName() const
{
    return mName;
}

// Adds a component to the entity.
bool Entity::addComponent(EntityComponent *component)
{
    // Did we get a pointer to a component?
    if(component == NULL)
      return false;

    // Check if a component of the given type doesn't already exist.
    if(getComponent(component->getName()))
      return false;

    // Add new component.
    mComponents.push_back(component);

    return true;
}

// Gets the component with the given ID from this entity.
EntityComponent* Entity::getComponent(const unsigned int id)
{
    for(unsigned int i = 0; i < mComponents.size(); i++)
    {
       if(mComponents[i]->getID() == id)
         return mComponents[i];
    }

    return NULL;
}

// Gets the component with the given name from this entity.
EntityComponent* Entity::getComponent(const std::string &name)
{
    for(unsigned int i = 0; i < mComponents.size(); i++)
    {
       if(mComponents[i]->getName() == name)
         return mComponents[i];
    }

    return NULL;
}

// Removes all components.
void Entity::removeAll()
{
    for(unsigned int i = 0; i < mComponents.size(); i++)
       delete mComponents[i];

    mComponents.clear();
}

// Removes the given component.
bool Entity::removeComponent(EntityComponent *component)
{
    // Did we get a valid pointer?
    if(component == NULL)
      return false;

    // Try to remove the entity.
    vector<EntityComponent*>::iterator it;

    for(it = mComponents.begin(); it < mComponents.end(); it++)
    {
        EntityComponent *comp = *it;

        if(comp == component)
        {
           delete comp;
           mComponents.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// Removes the component with the given ID.
bool Entity::removeComponent(const unsigned int id)
{
    // Try to remove the entity.
    vector<EntityComponent*>::iterator it;

    for(it = mComponents.begin(); it < mComponents.end(); it++)
    {
        EntityComponent *comp = *it;

        if(comp->getID() == id)
        {
           delete comp;
           mComponents.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// Removes the component with the given name.
bool Entity::removeComponent(const std::string &name)
{
    // Try to remove the entity.
    vector<EntityComponent*>::iterator it;

    for(it = mComponents.begin(); it < mComponents.end(); it++)
    {
        EntityComponent *comp = *it;

        if(comp->getName() == name)
        {
           delete comp;
           mComponents.erase(it);
           return true;
        }
    }

    // We couldn't find the entity and thus couldn't remove it.
    return false;
}

// End of File

As you can see an entity is a collection of an ID, name and a vector of components. That means that an entity is largely defined by its components. These are in my implementation described by the EntityComponent class.

EntityComponent.h

#ifndef __ENTITYCOMPONENT_H__
#define __ENTITYCOMPONENT_H__

// Include files
#include "../dependencies.h"
#include "Entity.h"

// Forward declarations
class Entity;

// EntityComponent class
class EntityComponent
{
public:

    // Initialisation and deinitialisation
    EntityComponent(Entity *parent);
    virtual ~EntityComponent();

    // Methods
    unsigned int getID() const;
    const std::string& getName() const;

    const Entity* getParent();

protected:

    void setName(const std::string &name);

private:

    // Static members
    static unsigned int mIDCount;

    // Normal members
    Entity *pParent;

    unsigned int mID;
    std::string mName;
};

#endif

EntityComponent.cpp

// Include files
#include "EntityComponent.h"

// EntityComponent class
// Static variables.
unsigned int EntityComponent::mIDCount = 0;

// EntityComponent constructor.
EntityComponent::EntityComponent(Entity *parent)
: pParent(parent)
{
    // Get new unique ID.
    mID = mIDCount++;

    // Check if we got a valid pointer.
    if(parent == NULL)
      delete this;

    else parent->addComponent(this);
}

// EntityComponent deconstructor.
EntityComponent::~EntityComponent()
{
}

// Sets the name of the component.
void EntityComponent::setName(const std::string &name)
{
    mName = name;
}

// Gets the ID of the component.
unsigned int EntityComponent::getID() const
{
    return mID;
}

// Gets the name of the component.
const std::string& EntityComponent::getName() const
{
    return mName;
}

// Gets the parent of this component.
const Entity* EntityComponent::getParent()
{
    return pParent;
}

// End of File

And just as the Entity class, the EntityComponent is also fairly simple. You might be wondering, though, how these components communicate with each other and other parts of the framework. The truth is that I’ve build an Event Manager on top of this entity system that takes care of that. Unfortunately that Event Manager depends on a third-party library called Sigslot And I think that such thing is beyond the scope of this post. Partly, also because I’m still tweaking my Event Manager myself and don’t feel comfortable yet showing that.

One of the things I mentioned in the previous article was Shigeru Miyamoto’s influence within Nintendo. I told that it would be interesting to see an antagonist of Miyamoto working within Nintendo. About two weeks after I had written that I read that Nintendo had teamed up with Masahiro Sakurai, the designer of Kirby and the well-known Super Smash Bros. series. But that wasn’t exactly what captured my interest. No, what I found interesting were this quotes by Nintendo’s CEO, Satoru Iwata:

“The thoughts of game designer Masahiro Sakurai and Nintendo have become one, and a new project has started. In order to expand what can be offered to the world through games, we will have Nintendo’s full cooperation and make something that Nintendo could not do on its own.”

“From our perspective, it’s not something that overlaps oddly with something that would come from Nintendo or those close to Nintendo. It’s something that can be made because Nintendo is backing you up, but is also something that Nintendo could not make.”

“If one were simply considering effective use of funding, we’d have went with a plan similar to Touch Generations. But that’s not I wanted. We want to make something that will be wanted even by the more hardcore game players, and something that offers new ideas.”

Link (Andriasang.com)

These quotes don’t gaurantee success, but it’s clear that Nintendo is willing to look at the new ideas. The reason for this can be found in another recent publication. Apparently Nintendo has hired a company to figure out how to sell more games to Wii owners. Wii owners aren’t buying any games; they’re just playing Wii Sports. This seems to be in line with an earlier statement from Sega that the Wii is “the most expensive board game on Earth” (link). So, in that light Project Sora isn’t a complete surprise.

According to Nintendo, Project Sora is bound to bring new ideas in the gaming world. What these ideas are nobody really knows, but I’m silently hoping that it will influence gaming as an art. Gaming went mainstream thanks to Nintendo’s efforts with the Nintendo DS and Nintendo Wii. It’s unfortunate to see people still consider games as a toy. Luckily it is no longer a toy only for children. But as many gamers know games are more than just toys. Myself I consider gaming as an artistic platform. It brings together visuals, music, narrative and interaction together in a very interesting way. Besides that games are also very suited for more serious applications such as education and simulation

It’s unlikely, though, that Nintendo is going to tackle this issue alone. Nintendo might not even be the “right” company to deal with the problem. Some of the most interesting games have come from the smallest developers. But it should be clear that this isn’t really only Nintendo’s problem. This is an issue that is of interest to everyone in the industry. If we want to push gaming as the big next platform, then it’s time to work together on this. And then we can hopefully finally speak of gamers as everyone would use it.