S.T.O.R.M. can only carry a limited quantity of ammunition for each weapon type. But on the way to the drill head, you will be able to find ammunition refill packs.

(f) Mechanical arm	(g) R.O.V ( Remote Operational Vehicle)	(h) Anessa
It's a useful part of the S.T.O.R.M. submersible. It enables you to collect ammunitions packs, oxygen refill packs, etc. or allows you to handle any object you will find on your mission. But be aware that this highly technical part of S.T.O.R.M. is also very fragile. You could loose it.	This mini submarine is remotely guided. It has laser beam weapons. It can be use in a hostile or narrow area where neither the S.T.O.R.M. nor the diver can enter.	This is the most advanced computer technology in existence. Its holographic memory bank technology offers you highly accurate advice and reporting on any problems that may occur. It has a female personality interface, and you can rely on it completely. Your best friend in a battle.

Recruiting new dealers was one of the strategic action to lead in order to enforce the position of the company.

On the right, is a former electronic shop with; his manager wanted to expand his business and revenus so that he signed an exclusive dealer agreement with me: I did provide wholesales, technical support, coaching and training.

François Loos — minister delegated to Industry — visited In-fusio this Friday as a demonstration to his support for the French video game industry.

Indeed, after UbiSoft last week, it is with turn IN-FUSIO—the leader of the play and services associated on mobile telephone—to be put at the honour.

Gilles Raymond—the founder of the company— accommodated, and with all the team, presented the company as well as the many projects in progress to him; and in particular, "ProjectX"—my project— a MMO mobile cross-platform technology for desktop/cellulars.

Let us recall that the ministers François Loos and Renaud Donnedieu de Vabres—Minister for the culture and communication—commonly decided to set up for the beginning 2006, as soon as the European Commission allows it, a tax credit intended to support and develop the French creation of video game.

This additional support, which should mobilize 30 million euros as of the first year, supplements the selective support brought by the Funds of Assistance to the Multi-media Edition (FAEM).

See the official press release from the Minister of the Industrie{title:"Press release only available in French"}.

During the summer 2005, I spent a month working on a way to improve my chances to win the French lottery and in August, I came up with SdlLoto.

SdlLoto: a realtime 3D visualisation with WarStation™ / Java

I used the WarStation port to Java I completed in July to develop SdlLoto.

I thought I could find a 3D visualisation that would help me in developing ideas I had.

Failling to find visual patterns

I initially thought I could find visual patterns in series of wining number, but I get to nowhere.

Machine learning: neural network and DNA-programming

Several years ago, I had explored genome programming on my HP4/CV in order to recognise letter glyphs.

For the lotto, I wanted to simulate multiple ways to draw 6 numbers and test it against all the previous actual wining draw I had in database.

I created millions of players, each picking a drawing method, and generated 1024 generations. Because the computing time was long, I made a server version of the sw and ran it on a server during the night. Once the best guess was ready I could run the 3D client version on my computer, get the guess numbers and play then for real.

In order to help tracing the whole process, I visualised the multiple genomes as a rolling bitmap image which I displayed at the bottom of the screen:

My conclusion was I really thrived to work on such a subject and learned tons of stuffs. But I never won the lottery though. No problem.

The project started in September 2000 in the pre-design stage. In addition to the concept document of the game, the very compact team (5 staffs) released the following pre-trailer. It was intended to communicate about the game to Kalisto members as well as to the publisher community.

As soon as we received the Xbox kit, during June 2001, we did port our PC engine in less than 3 months; we produced an interactive demo of the game for the London ECTS 2001 where it received an extremely positive welcome.
Many publishers were interested in publishing the game, and finally UBIsoft did sign the contract.

Unfortunately, with the bankruptcy of Kalisto in April 2002, the development was stopped and the promising title will never hit the market.

Making games on mobile is somewhat diverting: on one hand you have a very limited platform to work on — which is extremely demanding as you lack almost everything: memory space, speed performance — and on another you have to make people play to your game despite all these limitations.

You find yourself being back in time, while programming `80s systems: ZX-81, TO7, etc…

But things have changed: playing gorgeous titles on PlayStation and Xbox is common. How could people play '80s titles nowadays?

Trying to answer this question leads you to a less common question: what makes a mobile phone the unique play station when compared to others?

Connectivity! In space — you connect to others players — and in time — you "wear" your phone almost 24/7.

Connecting players

Connecting players in 2004 was something challenging. You want people play altogether, regardless of their actual handset technology — java, Brew, Symbian, etc. — and also regardless their operator.

Most of the available system widely supports HTTP connections. Sockets were not always available: for example with java, only MIDP2 defines a TCP support, but unfortunately, implementation was optional.

The system had to use HTTP support then. Unfortunately, performances of HTTP connections are not really impressive. Though HTTP is an applicative protocol that lies on top of TCP/IP, it only defines a peer-to-peer connections.

HTTP is a peer-to-peer protocol

Peer-to-peer basically means that for connecting from one end to the other end, intermediate routers or servers can relay the connection to the next "hop" by choosing what type of HTTP connection is the best suited for it.

All these "hops" are time consuming. Each per creating a new socket to the next hop, and potentially check and rewrite HTTP headers.

As a result, roundtrips performance drops dramatically when compared to direct TCP connection.

Radio to Internet connection

Another issue of importance is certainly the radio to internet part of the connection.
On the operator side, you don't really have access to the infrastructure. The only thing you know is that your connection is routed by a special equipment called an APN. It is the connection to the Internet, think of it as an HTTP proxy.
Behind it, on the operator side, IPs are local. When on the internet, you basically have the operator's public IP.
Some operators block packets that would get to "unknown" server IP, and in that case, you have to deal with the operator in order it lets you pass through the APN, down to your server.

How to authenticate players on your server

When HTTP connections arrives to your front server, IPs are usually not a mean to authenticate the player. At most, you can know from what operator he comes from, if you recorded all possible APN IPs somewhere in a database.
Some APN, gently add an HTTP header extension which tells what IMEI number the mobile has; but you shouldn't count on it, as this is the exception.

You have to rely on a custom, different mechanism of your own, such as a login/password system or a smarter thing.

What type of game to expect?

HTTP connection usually gives you an average roundtrip on GPRS networks of about 2400ms. Yes, you read it right: 2 and a half second to send a small message and get a response from the server.

If you tell me you can't do any game with such a latency, well my answer is: you're wrong.
Of course, you cannot design a racing car game, where you expect realtime collision detection over the network. 2400ms of roundtrip is of oder of magnitude to make such a game.
But if you design a game that do not offers high sensibility to latency you really can make funny games.
For example, we designed a multi-player version of the Microsoft/Rare Mr. Pants license.

Mr Pants and Battle Bubble Multiplayer

Basically, Mr Pants is an action puzzle game where you have to make rectangular blocks with the pieces you get form the game by rotating them appropriately in a limited time.

Every time you complete a block, the surface it takes is cleared and you collect bonuses and points.

Adapting the game to the above-mentioned constraints, the team designed a game play that wouldn't suffer from very high latency.
First, the screen of the opponent is also displayed on the player's screen in the top right corner, in order for you to look at his progression.
Second, when you complete a block, the game send a malus to the opponent, making its time limit to shrink a little bit, thus increasing the match pressure.
This way, it does not that matter wether the malus is coming "in-time" or not. What it counts is that it arrives!

As a result, the multiplayer version is really funny, and maintains the interest over time.