Google I/O 2009 - Writing Real-Time Games for Android

Skip the first 14.5 mins which is mostly introduction and a game demo, but I recommend to watch the rest.

Pretty pictures

When making a game, it is always nice to have inspiration to draw on.

One of my interests has always been space ships; and one good site that frequently have new concept art is Concept Ships.

Here's a few to show you what you can find there:

[Artist: Andrew Lee]


[Artist: Mike Doscher]


[Artist: Alfredo Dosztal]

Unity - Game Development Tool

Unity (or "Unity3D" as it was first known as). It is currently at version 2.5.

It is a multi-platform game development tool, designed from the start to ease creation. A fully integrated professional application, Unity just happens to contain the most powerful engine this side of a million dollars.

Besides publishing standalone games, it has its own web player add-in (the download is about 9 MB) for browsers and IPhone publishing (at an additional charge). Currently in two versions: Unity Indie (US$199) and Unity Pro (US$1499).

"Unity supports three scripting languages: JavaScript, C#, and a dialect of Python called Boo. All three are equally fast and interoperate. All three can use the underlying .NET libraries which support databases, regular expressions, XML, file access and networking.

Scripting is frequently thought of as limited and slow. But in Unity your scripts are compiled to native code and run nearly as fast as C++. You get the fast iteration times and ease of use everyone loves about scripting languages."

[Source: Unity3D.com]

That seems very believable after viewing their Tropical Paradise demo.

Also, according to some bloggers, it is apparently easy to convert a game written with Papervision3D (Actionscript) to Unity. Something which they mostly do so as to publish their games to the iPhone.

Something to comeback to once I made something with Flash.



Update:

Here are some reviews/comments on Unity:
DevMaster.net - Engine details of Unity
StackOverflow.com - What’s the best indie game development environment?

Interview: Jonathan Blow discusses his platformer, Braid

Jonathan Blow is the developer of Braid, a platformer that makes use of the manipulation of time to solves puzzles. The game first came out on XBox 360 Arcade, and is now out on PC.

You can download the demo from Steam, here.

It has a lot of similarities to platformers like Mario done on purpose to make it sort of a platformer parody. This also allows Braid to introduce the concept of time manipulation (rewind, slow, etc) from early in the game. For example, your character never dies in Braid, instead you are allow to rewind when that happens.

Braid trailer from David Hellman on Vimeo.

[Source: braid-game.com]

Here's some excepts form his interview with Leigh Christian Ashton of TIGSource:

"I have to admit I don’t really enjoy programming very much any more, because in order to get things done I have adopted a style of programming that makes it as simple as I can, so that it is just easy to get things done, and it only requires time and a lot of typing. So I am not really solving any difficult puzzles or challenges when programming, as beginning programmers might. On the plus side, this means I can program in a relatively efficient manner; on the minus side, it’s a less-engaging activity. I make up for that on the design side; whether I am making a prototype or a full game, it’s about exploring some interesting space of ideas. Programming is now just the implementation detail of how I do that exploration.

It’s not really about innovation so much as exploring interestingness. There is this idea of chasing innovation in game design that I used to be a big proponent of, but that I now suspect is a little bit misdirected."

"I try to encourage people to be willing to delete stuff that is mediocre or just kind of good – or at least put that stuff in a closet for some future day – so that they can focus on the stuff that is great. Many people don’t think that way, though. When it is so hard to get anything substantial done, you just don’t want to throw away any of your hard-earned progress."

"I think gameplay innovation can result in things that are interesting, but at the same time it doesn’t automatically result in something that is deep—often it’s a gimmick. I am interested in deepness and richness of game design. At the same time, I think if a designer is working on something he really cares about, and is really exploring some ideas in his own style, bringing his own particular insight to the table, then he will automatically come up with something different than most other games; furthermore, this will be a deeper, more-compelling kind of innovation."

[Source: tigsource.com]

So innovation does not mean interesting, but interesting usually mean innovation.

Also, the phrase "less is more" comes to mind when he challenges others to delete anything that is not extremely core to the experience. While this may cause a game to receive a great review, it does not necessarily mean the game will be played for a long time (and thus maximizes profitability). Will have to see how many people are still playing Braid a year from now.

Concept: Procedurally-generated content

Designing content (like levels, models, maps, items, etc) by hand can take a lot of time, so this acts as a limit the amount of detail that is put into a game.

The alternative is to generate the content procedurally, which means to create programs that do the design for you in a random and believable way.

One early example is the games Diablo which always create new areas and items so that players never have the same experience twice.

Here's a video that demonstrate this concept:

[Source: ShamusYoung.com/TwentySided]

There is a HQ (Higher Quality) version which you can view by clicking on the "HQ" button on the bottom right of the video.

If you like it, you can download it as a screensaver.
(Note: press "F1" for settings)

Concept: Complexity... the good and the bad

An ex-colleague and good friend of mine, Andrew posted the following, and I thought it would be good to share it. Here it is paraphrased to be more generic:

There are two types of complexities in games: inherent complexity and emergent complexity.



The inherent complexity is inherent within the basic mechanics of the game. Those things that you need to know in order just to be able to play it. This complexity includes the rules and interface to play the game.

In a board game, this complexity is a necessary evil as it is what creates the game in the first place. It defines the shape of the board, the pieces and the basic constraints on their movement. To play the game you must understand these constraints. (Perhaps this is less so in computer games where the interface prevents you from straying beyond them, but an overall big picture view is still really quite essential even if some details can be left till later).

To be able to play the game you need to know this. Without it you can still be clicking away but much of what is going on around you wont make sense, and I'm not sure that you could be considered to be 'playing' any more than a monkey behind the wheel of an out of control truck could be considered as 'driving'.



Then there is the other type of complexity, emergent complexity.

This includes our understanding of the consequences of the basic mechanics, and the strategies and counter-strategies we apply to playing the game.

If the inherent complexity is the game board, then emergent complexity is the game that is played upon it, for it is but a function of the various strategies, techniques and styles that players come up with given the constraints imposed upon them by the basic game mechanics.



There is a very critical difference between the two types of complexity and it is this difference that makes inherent complexity bad and emergent complexity good.

Inherent complexity is a roadblock that must be passed before a player can participate in the game. The bigger the barrier the fewer who will pass it. Learning the details that make up the inherent complexity will not let you compete better, it will merely let you compete.

It follows that we would want to minimize this aspect.

I wont argue that there is a certain satisfaction - especially for the geekier among us - in learning systems of byzantine complexity and memorizing vast tables of obscure statistics and the such, but I think its accurate to say that for the most part players would like to get their basic training out of the way and get down to the real business of playing.

Emergent complexity does not prevent you from playing.

In fact it is the secret sauce that keeps you playing, because every time you play you learn a little more about the game. Something you think you did wrong this time and are eager for next time to try and correct it. Some new idea you want to try applying in the next game.

You will notice I use the words 'think' and 'idea' here. These are not cold hard facts to be learned, instead these are subjective. They are opinions, styles, choices. Making these choices is playing the game.

Eliminating the emergent complexity means eliminating these choices. Eliminating the emergent complexity means eliminating the gameplay.

So I want people to minimize the inherent complexity and maximize the emergent complexity. Because while the inherent aspect is the price of the ticket, the emergent part is the game itself.

To finish with an example, take a look at the games of Chess and Wei Qi. Both have very simple inherent complexity but extremely high emergent complexity. They take but an hour to learn yet a lifetime is needed to master them.

I gather that both games still enjoy a certain level of popularity despite having been released quite a while ago.

[Source: forums.sjgames.com]

With this in mind, I always aim to design games that are extremely simple to get started with, but have a lot of depth that can be slowly learnt over time.

I think this is the simple reasons that some good games become so popular, and other good games rarely have more than a small fan following.


Make a game with too much inherent complexity and few people will finish learning to play it, whereas if you make a game with too little emergent complexity and most people will get bored after playing it a while.