Category Archives: Uncategorized

Astro Lander, a development summary

This project started as a simple remake of Lunar Lander.

Lunar Lander relies on a 2D gameplay with a simple use of physics and it exactly what I was looking for. I’m going to explore in this post how it finally evolved into something bigger, iteration after iteration.

A long list of improvements.

The initial change I wanted to implement on my remake was a multi directional scrolling, to offer a larger game area.
I built rapidly a minimalist level made of cubic blocks and started to write the physics and the controls of the Lunar Lander.
I found out that the game play could be accelerated, and then I made the ship to move faster. Rapidly, the challenge evolved from “land softly” to “navigate softly and avoid the walls”.
The goal of the game would be not only to reach a specific point, but also to collect a series of items scattered across each level.

The controls.

I started to focus on the controls of the ship. A Lunar Lander is basically about controlling the ship’s reactors versus the gravity and the inertia.
But I wanted to avoid the usual problems related to the rotation of the ship. If the player is in charge of both the thrust and the roll angle, a situation might occur where the ship is upside down and the thrust direction will sum up with the gravity, thus sending the ship even faster against the nearest wall.
To suppress the frustration inducted by such a control scheme, I wrote a simple routine that always controls the rotation of the ship. The player is free to move in any direction, the physics engine handles all the collision and physical responses, the ship can translation, rotate, bump into walls, but in the end it always remain properly oriented.
In my opinion, this is a good compromise for a physics-driver action game, where the physics engine makes the game looks real but doesn’t spoil the gameplay.

The code of this routine takes only a few lines of code :

function AutoAlign(item)
local _align, _speed

// Get the current orientation
local _rot_z = ItemGetRotation(item).z
// Get the angular speed (if the ship is rotating)
local _ang_v_z = ItemGetAngularVelocity(item).z

// Magic factors applied using an empirical approach …
_align = Clamp(Abs(RadianToDegree(_rot_z)) / 180.0,0.0,1.0)
_align *= 250.0

// … that defines the strength of the torque (angular force),
// applied on the ship to stabilize it
_speed = ItemGetLinearVelocity(item).Len()
_speed = RangeAdjust(_speed, 0.25, 0.5, 0.0, 1.0)
_speed = Clamp(_speed, 0.0, 1.0)
_align *= _speed

// Applies the torque
ItemApplyTorque(item, Vector(0,0,-_rot_z – _ang_v_z).Scale(_align * ItemGetMass(item)))

One of my friends who works in the game industry always told me that I needed to refine the controls before doing anything else on the game. During my past attempts at making a game, I disregarded this advice, and started with the level design. I eventually understood that Romain was right.

To bring the ship in motion, the player will only need to trigger the 2 side thrusters by touching the 2 halves of the screen. Such a basic control is perfectly suitable for smartphones and tablets, allowing you to concentrate on the game without having to constantly check that your fingers are properly positioned on the screen.
With the help of Emmanuel, I was finally able to tweak the core routine that drives the ship and defines the way lateral forces are applied to it. It ended up with the exact kind of behavior I was looking for, so the level design could start, at last!

The Level design

As I knew I couldn’t spend too much time on the graphics, I headed for the simplest method I could think of to build the levels : “lego bricks”. This technique, based on blocks, presented two benefits to me :

  • it is cheap in terms of time investment, because you only need to prepare a few blocks and you’re free to work with the GameStart editor. I didn’t have to constantly exchange back-and-forth between 3dsMax and GameStart.
  • it let’s the door open to a future extension that brings a lot of value to a game : a level editor that the players can work with to assemble new levels from scratch.

It has drawbacks too, of course. It’s a bit heavier for the engine to handle a large list of split blocks, and the overall visual aspect tends to be less realistic.

What’s next ?

Now that the game is almost done, with a series of 24 different levels, all we need is to polish the final builds both for iOS and Android platforms. As soon as the game is released, I’ll be able to focus on the next big implementation : the level editor.

In the meantime, you may enjoy the gameplay video below :

Global Game Jam Paris 2011

Global Game Jam Paris 2011 is now over. It took place at ISART, School of video game, digital art & design. The place is great, the organizers brought a perfect support. The Jammers were amazing.

The GGJ Concept really brings a full cycle of the life of a video game. It’s definitely the best concept of game jam I’ve ever tried (compared to Demoscene events or TigJams, for ex.)

Game list

Borrowed from Olivier Lejade’s twitter :

Tweet Uranus
Follow the white light
Appetite for Extinction
Dark Naze
Master Beer
Extinction des feux
Light Extinction
Colors Wars
Don’t win!
Light Cylinders
VR Escape

GGJ Paris Website :

Isart Website :

A few notes for my next jams

(and for any future jammers I guess)

1. Prepare a file-exchange solution :
You never know what kind of network environment you will meet in a Jam. I’ve done jams with an almost un-existant network support (cybercafΓ© with overloaded wifi). Most of the time, you will have some network ports unavailable, especially those for SVN, Remote Admin, Unity Asset Server…
In that case, with such an hostile network support, how are you gonna exchange files rapidly, including multiple revisions, with your team ?
At the GGJParis 2011, we found out that DropBox was a rather good solution.
Preparing a small laptop that will serve as version/asset server can be handy as well, depending how much stuff you can carry with you.

2. Know your effing tool
If you’re going to create a game in such a short timespan, and embark a whole team with you, you’d better know your tool(s), your pipeline and their technical pitfalls.
During the making of a game, each time an idea arises, ask yourself : “have I already done this with my tool/language ? have I already succeeded ?”.
If it turns out that you never really tried to create an AI, code a level logic, setup a GUI, import a full rigged character into your engine, it’s rather unlikely that you’ll be able to do this during a jam, in a timely manner. And even if you do, it might spoil all your precious time, and you won’t have any left to think about/work on your game design.

3. Prepare your computer
Don’t arrive at a Jam with a PC that “just” needs a “quick reinstall”. Reinstalling Windows usually take a few hours, for you will have to hunt for the proper network driver, the right Redist, the latest Nvidia driver, and then make sure your tools work properly. It may only take a 2 or 3 hours, that’s A LOT in a 48h game jam πŸ™‚

4. Bullet proof your engine
You wrote your personal 3D engine yourself. You’ve tested every part of it at least once and you know it will work. But have you tested all the features altogether in a single project ?
It sometime happens that using several features of an engine suddenly shows a loads of side effects and … bugs. And a game jam is not exactly the right place do debug your engine, especially a C++ engine πŸ™‚

5. Talk pipeline/workflow before
If you are about to choose a team to work with, it might be wise, before embarking everyone on the same boat, to check that your workflow habits, and pipeline knowledge are compatible … unless you want to learn a completely know workflow during the Jam πŸ™‚
However, I’ve met some guys who never worked together before, and they managed to bullet proof a common 3D pipeline and finish a proper game within 48h !

My personal hierarchy of coolness

I’ve done a few events during the past years. Among them :

I’ve probably been to half a dozen of demoparties, between 1995 and 2005. Demoparties are cool, but most un-structured. You work on the kind of production you want (non interactive demo, usually), on the theme you’ve chosen, within a totally free timeframe (several years to a few hours).
Too much liberty ends up in something that became way too unstructured for my own amusement. I found out that 64k demos, with far more constraints, can be much beautiful and fun to do and watch.

I recently found, a TigJam Berlin 2009, that GameJams can be more interesting than demoparty, for the very reason that if you game is not FUN, you will know it RIGHT AWAY πŸ™‚

GGJ might be the ultimate achievement for me, because the whole event is really and wisely structured. The GGJ 2011 was a really intense experience to me, and I learned on many levels (technical, social …) so much more during 48h than all I could remember of my past years of demopartying.


Trying to model an outdoor scene.

All these dark level designs I previously started made me feel a bit gloomy… Going outside for a bicycle ride, and visiting the huge city of Berlin, I felt I should imagine something less confined, so I started to doodle this open air design.

I tried to imagine some sort of lost ruin, up in the sky, that the player would reach through a long way made of traps & elevators.

no images were found

no images were found

The screenshots were grabbed directly from the engine, with infinite shadow maps & SSAO, yaye πŸ™‚

First test of level design …

Once all the (old) assets where converted to the new engine, I tried to assemble that and design some rooms, with gates, elevators, and levels.

The main idea to far is to design an acceptable gameplay, and not to polish the graphics until there’s something funny to play πŸ™‚

no images were found

no images were found

no images were found

no images were found