Welcome to the second part of this series of articles.

The first part was basically about what I did before working in videogames for a living.

This one was supposed to cover my first 10 years working in video games, ¹, but I realized that already covering both Adeline and Héliovision was more than enough for one article.

That's a shame because I love round numbers and symbolic dates!
I need to add an important disclaimer: All the things I'm writing here are based on a combination of memories, personal feelings about how things were at the time, which I tried to cross reference from other sources like my old backups or dates on websites such as Moby Games in order to get the dates right.

I may have done some errors, attributed some things to the wrong persons, or gotten a bad date. Don't hesitate to point out errors or to comment if you have your own take on the story. As long as everybody stay civilized and honest I will not censor the messages.

Adeline Software: 1995-1997

Mit was already working at Adeline Software when I joined.


At the time I had a subscribtion to one of the most famous French videogame magazines, TILT², which for various reasons ended up out of business.

Instead of a refund I got a subscription to Joystick, and in the first issue I received was a job offer from Adeline Software looking for programmers.


I was not really interested at the time because I wanted to get my Bachelor Degree. Instead I helped Mit collect materials for his resume and books, he took the train for Lyon and got the job.

One year later Adeline had grown and they needed more people, so Mit asked me if I was interested. I took the train for Lyon, and had my job interview with Frédérick Raynal³.


It turns out that I got hired mostly because of the Phaleon Demo.

Raynal was not interested by demos at all, but he reasoned that if somebody was able to spend two years of their life working on a demo, for free, and get it released... then probably the same person would be able to work on a video game until it's actually done.

Which I guess makes perfect sense.

On January 1st 1995 I was in Lyon - recovering from an exhausting good bye party with my university mates -, and the day after I was in the office of Adeline Software having absolutely no idea about what I would be working on.

My work started by learning the Adeline Libraries: LibMenu, LibSVGA, Lib3D, ... that was kind of a revelation for me because I never used any libs before. It's nice to learn new and exciting things!

I also discovered the Watcom C Compiler and the DOS Protected Mode.

I converted my University ZBuffer house project as a way to learn the new development environment, and to my stupefaction the program was running twice as fast and at four time the resolution (SVGA vs MCGA) on the same machine.

I definitely considered PC as a serious machine after that.



Adeline Software had just released the PC version of Little Big Adventure, and was now working on two new projects: Little Big Adventure 2, and Time Commando.

Mit had evaluated the feasibility of porting Little Big Adventure on the 16 bit consoles and even had a prototype of a tile based software renderer on Megadrive, but it was clear that the machine was not fast enough for a full game port.

Fortunately, 32 bit consoles were one their way, and soon we had a Sega Saturn, Sony PlayStation and Atari Jaguar development kits.

Since we were limited in manpower we could only choose one, so we had to devise some scientific way to evaluate which one we will use.

The Jaguar devkit looked very amateurish and hacked together, with multicolored cables to connect a console to the host PC. The documentation was basically a random mess of floating pages. And there was floppies. Many floppies.

The Saturn devkit looked ok. There was decent documentation, and there was ok demos.

The PlayStation devkit was the most impressive: Large ISA cards, professionally printed CD Roms, thick glossy paper documentation in mean looking black binders with the PSX logo on each. And there was the dinosaur demo.

In the end we picked-up the PSX because it looked cool, shiny, and had a kick ass dinosaur demo.


There you go, professional testing for ya.

The work started by porting the PC libraries to the PlayStation. Mit did most of the low level ones (maths, rendering), while I did most of the system ones (menu, files).

Time Commando (PC/PSX)

When we were done with the libraries we actually started on the port⁴ of Time Commando.


The programmers working on the PC version were also the ones who had written most of the tools, and when the production pace increased, they were not able to work on both the game and the tools, so I basically was asked to take over and that's how I started my career as tool programmer!

The first tool was the Scene Compiler, which basically was a command line program used to convert a textual description of a Time Commando level to either a HQR or BIG file containing all the resources used in the level⁵ and that could be directly be loaded in memory and used without any allocation.


Feature wise, the tool contained a script language compiler, texture page generator, LZ77 compressor and resource allocation for the final archive.

This tool is also indirectly responsible for killing our NT 3.51 server: One day we had to fix a bunch of bugs signaled by our partners at Activision, which involved doing a lot of small tweaks in various levels, and then rebuild the level to binary format so a new version could be built.

The way I solved that was to write UPDATED.EXE which basically took two file paths as input parameters and would then return an error code value based on which file was the most recent one.

Then one each of the available machines I ran a small BAT file similar to that one (each one with a different level being tested):

:LOOP
updated path_to_level_xx.sce path_to_level_xx.big
IF ERRORLEVEL 2 GOTO LOOP
compile path_to_level_xx.sce path_to_level_xx.big
GOTO LOOP

Basically all this script do, is to check if the scene has changed, and if yes rebuild the big file. This was enough to get Windows NT spend 100% of the CPU time in the kernel⁶.

The second large tool I took over was the Time Commando Editor, aka TCED.


TCED was an interesting mix of things. Think of it as an integrated development environment from where you could load and save game levels, place enemies, bonus, define the camera rate of movement, position light sources, but also start your favorite text or bitmap editor or reset your Playstation development kit.

There was quite many other tools I worked on.

I had to write the PSX optimized version of the background movie streaming (because we could not use the built-in MDEC decompressor), which in turn had me write the PSX specific variants of the Adeline Compressed Format (ACF).

I also wrote the game end-credits sequence editor where each of the Adeline employee appears on a virtual stage as one of the game characters.


Most of the core of Time Commando PSX was written by Mit, but I still wrote some code:

• All the menus and settings, including the pause menu
  
• The script intepreter
  
• The tunel traveling effect
  
• The spline based shadow
  
• All the 2d post processing effects (fade to grey, anti-aliasing)
  

After Time Commando was released, around the end of 1996, I discovered in a magazine that somebody had created Euphoric, an Oric emulator.

I downloaded it, and the magic was back!

There was even a way to program in C and assembler directly on the PC.

So I gave a shot and released a small preview of what Dungeon Master could look like on the Oric.

It was not particularly advanced, and I stopped mostly because I did not know how to use the floppy disk drive at the time, and realistically this game was not usable on a tape system.

I may finish it one day, but the game would be very different: Graphically speaking it would be redone to use the latest AIC advancements, and the whole game concept would be rewritten to be better fitting to a computer without a mouse.

LBA PSX

The big boss wanted us to start the port of Little Big Adventure 2 on the PlayStation.

The problem as Mit and I saw it, was that the program was still being developed. It would be a lot easier and faster to port the original Little Big Adventure.

In the end we got an agreement: If we had two months to port LBA 1, and then we would work on LBA 2.

We said ok, and started crunching.


Long story short: We did not manage to do it in two months, it actually took four, but it's also a game consistently praised for the quality of the port ⁷.

There are two versions of LBA for PSX. The Japanese version, and the European version.

The Japanese version was created from the PC version source code using an automatic code translator which converted x86 assembler to C.

The result was an absolute catastrophe, which ran at possibly 10 frames per second in 320x240.


The European version (written by Mit and I) on the other hand, also started from the PC version source code, but we rewrote everything that did not compile out of the box (mostly parts with a lot of assembler) or ended up running too slow (because it was designed for the way a PC renders).

Our version was certainly different it ran in 640x256 at a consistent frame rate, all the musics and cut-scenes are present as well as the three spoken languages and five written ones, and as a bonus it also loads fast and you can save at any time.

The biggest issue on the port of the game was the memory. The original game required 4 megabytes of memory and 8 megabytes on the hard-drive, while the PlayStation only has 2 megabytes of ram and a 2x CD-Rom drive.


My work on this project was mostly the data converter which loaded the original PC data and converted it for something more efficient. I also worked on the texture page generator used to pack all the small bitmaps used to generate the isometric background in the most memory efficient way⁸

The project was mostly a success, but it also was the end of the console team at Adeline.

There was a number of issues in the company, both financial and structural. Mit wanted the console group to have a larger role and not just have it as a porting machine.

That was refused, so he decided to quit.

The way I was asked about what I would do next was far from being subtle or smart. Instead of asking me if I wanted to take the position, I was basically told that either I was following Mit or would stay at Adeline but that there would be no more console development.


Since Mit and I shared an apartment at the time, I was present when he signed his contract with the new company. The boss asked me if I would be interested to sign as well so we discussed the terms.

The answer was a no-brainer: I would get a better salary, and I would be working on our own console game written from scratch: Swifty!

Héliovision also had a PC game in the pipeline, with a never seen before voxel based technology, HExplore. That sounded intriguing and interesting.

Good bye Adeline, Hello Hélio!

Héliovisions Productions: 1997-1998

My work at Héliovisions started on a the 1st of April 1997. Retrospectively, that may have been a sign of things to come.

Hélio will probably stay in memories more for the epicness of the parties, the Star Craft and Quake sessions, the management decisions and global chaos... than for the games⁹.

Soon after I released my first attempt at demo making on the Oric, with the well named Big Scroll, which featured... well... a big scroll, an Atari ST music, and some volume meters.

Nothing incredible really, but one need to start somewhere.

Swifty (PSX)

At work, Mit and I were busy working on our own tech, the GLib¹⁰, inspired by what we were using at Adeline¹¹. Soon after we were able to start building our own tools, starting by the level editor for Swifty!


The rendering looks pretty primitive, but the reason is that it was actually a software reimplementation of the entire PlayStation 1 rendering hardware. The company could not afford to order more than one PlayStation dev kit, so we had to find a way for the artists to edit their assets and build their levels efficiently without having them to queue to access the only dev machine we had.

The resulting engine was definitely not as fast as it could have been, but it was accurate enough: It fully supported the ordered dithering, gouraud shading, transparency, 4 bit textures, texture wrapping rules, palettes, and even emulated the triangle ordering bugs and texture perspective errors.


Around Summer 1997 the company was bleeding cash and was in serious need of capital injection.

The solution was painful but necessary: We had to stop developing Swifty and instead accept to work on The Smurfs for Infogrames.

Hexplore (PC)

During all that time, the Hexplore team was struggling, trying to finish the game in time. The artists had to modelize 3D Voxel assets using Deluxe Paint, while the level designers had to use a world editing tool without any mass update feature: In order to tweak the balance of the game they had to manually select every single monster, treasure, door or trap, and set the parameters for each of them.

GripIni was their savior. This insane tool I hacked in few hours was basically a multi-criteria search and replace program which was able to recursively move down the list of data files to replace values by other when certain criteria were met.

Extract of the documentation:

At least 4 parameters are required:
1: The type of INI file ('D' for doors, 'N' for npcs, 'S' for stones
2: The reference string in the section
3: The string to search (with optional '*' wildcard)
4: The replacement string

So with the following request:
GRIPINI D DOORTYPE=FOO FLAG=15,33*37,99,12 BAR

All the Doors of all the DOORLIST.INI files found in the current folder structure, which contain the string 'DOORTYPE=FOO'
and have a line containing the substring 'FLAG=15,33' followed by '37,99,12' (with anything in between) will have he line replaced by the string 'BAR'

In ENHANCED mode the first parameter is the number of matching strings to use.

Now try to imagine how scary this must have been to use that, knowing they were directly working on the files, and without any easy way to find out if they did a typo which actually destroyed all their data.


Looking in my archives, I discovered I also wrote CBCopy and UpdateVB; respectively being a "CB0 Copier for HExplore" which apparently copied games files are the correct location on the final server based on some naming convention involving Episode, Level and Map numbers in the file name, and the other one being a "VB1 Copier for HExplore" which apparently was doing some recursive file scan and copied stuff around.

I have absolutely zero memories of having written these, but they were probably some attempts at fixing a broken workflow.

No wonder the development of that game took longer than expected...


In February 1998 I attended the Volcanic 4 demo party, and presented the Just Oric demo.

As far as I know, it was the first time ever there was an Oric in a demo party, so people were a bit surprised - to say the least.


From the colors and style you can guess easily that it was pretty much based on the code of the Big Scroller, even the end tune happens to be the same one because it had already taken me a lot of time to find a tune that sounded decently at the time. Nothing was automated back then.


Still there was some new code: The sample player (using the Atari ST Replay volume tables), the distorted logo, and the triangle rasterizer.

The blood dripping animation was done by Greuu, one of the amazing artists we had in the company.

Doki Denki Studios

An 'interesting' development happened at the demo party: The management of Héliovision was present at the party when one particular prod was shown. They were very impressed and contacted the team who made it.

They eventually were hired as the third video game team inside the company, and the company itself changed its name from Héliovisions Productions to Doki Denki Studios.


They were young, they were ambitious, they programmed in C++ while we were still doing C, they thought we were old and unwilling to cooperate. The end result is kind of predictable: You can hardly have a positive work environment when the various teams are spending more time dissing each other than actually getting work done.

In a funny turn of events, they were supposed to work on a new game on Dreamcast... which did not have any decent C++ compiler at the time.


The PlayStation team was having hard times.

Without citing any name, let's say that there was a mix of people wanting to to "become Caliph instead of the Caliph", drug use, overtime burn-out, conflicts about how the projects should be developed, and finally somebody got heart broken for the first time.

At least, some of the projects were going forward.

The GLib

The UI library was definitely looking much better, it has both support for software and hardware (3Dfx Voodo Glide) rendering with user selectable color schemes and texture skinning, full support of Hercules monitors for real time debugging and profiling, and many of the tools were getting quite advanced:

• InterMat, a simple way to edit the interaction between different materials how they sound, type of damages
  
• BigMak and MakeBank, basically a set of archive management tools to handle our BIG files.
  
• LangageParser, a combined text editor, interpreter, compiler and debugger for our scripting system
  
• TimeSync, a tool to edit complex bezier curves to defining trajectories of things like platforms or monsters at specific times.
  

The Smurfs (PSX)

Infogrames wanted us to present a plan on how we could make this Smurf game with a very aggressive schedule.

Disney had just released the game Hercules, which displayed 2.5D graphics with a very clever use of parallax on simple bitmaps. I thought that would work for the Smurfs and made a small prototype showing a gazilion of fast scrolling Smurf houses and trees with a fully animated character using the sprite sheets of the Megadrive Smurf game.

The Infogrames producer we had at the time was very happy and wanted me to come at their offices for a meeting with their brand manager to show the prototype.


The meeting did not go very well.

One of the things she said was "Well, I hope you have something exciting to show, I want to show Disney that not all games have to be crappy 2D shows like Hercules". Oops...

I clearly said to my boss that there was no way we could do a full 3D platformer in 6 months, at least not without taking shortcuts all over the place.

I refused to take that responsibility and in the end I gave my resignation letter and accepted a position at a new studio, Eden Studios, as lead programmer for the Dreamcast version of V-Rally 2!

I finished some of the on-going work on the tools, and in October 1998 I started by new job, which will be the third article of this series.

And by the way, I was indeed correct for The Smurfs: The game was finally released in December 1999, more than one year after I had left.

On the Oric front, 1998 was not a sterile year either.

Motivated by the feedback I got from the Volcanic Party demo, I started to work on more serious effects, which I released during the year.

The first was my first actual real 3D code, a 3D Cube, and the second was a Textured Tunnel such as done in PC demos.

---