Welcome to the third part of this series of articles.

The second part was about my time at Adeline Software and Héliovisions Productions, now this entire article will cover the 1998-2005 period at Eden Studios (aka Eden Games).

Help wanted

I joined Eden Studios in October 1998 and immediately started to play with the Dreamcast development kit.

Soon I had my old ZBuffer house moving smoothly on the screen.
The result of the experimentation was really a mixed bag: Between the non ANSI compliant Hitachi C Compiler, the multiple redundant API (Direct X if you decided to go the WinCE way, the high level Shinobi, and the lower level Kamui), the documentation errors, and the quality of the tech support... it was difficult to judge of how easy or not it would be to port V-Rally to the Dreamcast.


As it happens, it was not really a problem I had to handle right now.

Eden had two teams, one working on the Nintendo 64 port of the first V-Rally, and the second one working on V-Rally 2 on the first PlayStation.

Both teams were having trouble finishing their products on time, so everybody had to come helping, which is what I did for a good part of the following year.

Year of the Moulinette¹

When I first checked my archives for the year 1999, I found out that I had released nothing.

No games, no demos.
On closer examination, I found out that I actually spent that year writing command line tools, converters, filters, documentation generators and file integrity checkers, either used to fix the broken asset pipeline of the PlayStation team, or later to convert PlayStation assets to PC and Dreamcast compatible formats.

Here is a partial list of the tools I had to write:

• Vahiné²: Designed to pad files to specific sizes to improve the disk layout
  
• Catalog: To generate HTML documentation so we could locate assets on the network
  
• MakePak: Another HQR/BIG/BANK format, designed to be accessed by direct seeking at offsets in the file on disk
  
• MakeZap: Like ZIP, but without the useless information and allowing decompression without intermediate buffers
  
• ScriptCompiler: To compact the SCR files describing the menu sequences of the game so they are more efficient at run time
  
• ScriptIntegrator: Used to extract things to localize from the UI scripts, and then to generated localized version of the menus
  
• SplitDSC: No idea what it does, but it involves DSC, GRP and V2D files!
  
• VagConv: To convert PlayStation audio files in VAG format to RAW audio so they can be used on PC and DreamCast)
  
• Pcx2Tim: To batch convert images to the PlayStation format so they can be used in the menus
  
• ReplayPaker: Test of AI drivers actions recording and replaying code
  

Menu hell

Slanted graphics...

For some reasons, the person who designed the menu system of V-Rally 2 thought it would be a good idea to have things slanted instead of being aligned on a grid:

That would make things a lot more dynamic and elegant.

At least that was the idea.

In practice, we had to use a mix of bitmaps for all the things such as icons, texts, numbers, rounded corners, background pictures, masks, and actual vectors for lines and progress bars.

In the real world the various consoles on different territories have different resolutions, and having slanted bitmaps meant we could not just rescale independently the layout on the horizontal or vertical dimensions: We had to keep a correct aspect ratio for the UI for 320x240 (PAL) and 320x256 (NTSC) on the PlayStation, 640x480 of the Dreamcast and for all the resolutions you can think of on the PC.


All these menu were composed in text files (the famous SCR files), describing both the layout, the list of resources they used, and the logical mapping from one entry in the menus to where it was linking to in another menu.

I do believe we spent weeks just on reexporting, converting, tweaking, adding +1 here and -2 there, changing two pixels on a corner bitmap so it looks less ugly when it joined a line before finding out it did not work on another menu screen because of some overlayed bitmap.

Anyway, in summary, all I did on the PlayStation version of V-Rally 2 was to write tools to improve the work-flow, and learn things not to do while working on the menus, and yeah implementing almost the entire menu support for the peripherals, including the ones you never heard of such as the NegCon.

Next gen, here we come

Somewhat during the year 1999 we finally managed to get back to the PC and Dreamcast versions of the game.


The PlayStation version was still being worked on, but at least now there was one dedicated programmer for the PC version, and one (me) for the Dreamcast version.

We also got our own tool programmer, who basically spent his time tweaking the export format to accommodate our needs.

This project remains to this day one of the high points of my career: The amount of overtime was insane³, but I survived it and I'm as proud of the Dreamcast version as I'm sure Sammy is proud of his PC version.


What was special for me is that basically it was a one man port.

Sure it was a port of existing code made by the PlayStation team, but still I had to convert all the code of the game and libraries, and to write most of the assets conversion tools.

As a result I became probably one of the most all around knowledgeable Dreamcast programmer at the time.

The people at Sega on the support forums thought that I was posting questions on behalf of our team while it was really only me posing questions about audio, video, texture formats, state management, bugs in the api, questions about obscure points in the documentation, file handling, deployment tools, technical requirement checklists, movie codec licencing, and so on and so on...


In 2000 I attended the Sega Developer Conference in London.

When I gave my name at the entrance desk, two Sega support guys looked at me with raised eyebrows and asked "Oh, are you *the* Mickaël Pointier from Eden Studios?"...

No comment.

Feature wise, the PC and Dreamcast versions of the game are pretty much identical.

Quality wise, the Dreamcast version is much better.

The time the PC team spent fixing PC specific issues caused by the different versions of Windows, drivers, sound and graphic cards, installation setups, etc... I spent profiling, tweaking and polishing the Dreamcast version.



Thanks to the added power we were able to improve quite a lot over the PlayStation version.

They load data much faster and there are no loading between menu pages, the switch to VGA resolution and higher really helped improving the visual quality, the game now ran at 60fps all the time⁴, and the track editor was now able to handle much longer tracks, it also had welcome additions on the game side such as a much more tolerant physics and dynamics engine, more forgiving track design with less violent collisions⁵, and some visual indication of the damages your car suffered.


Finally, because Infograme failed to give the complete credits in the game, I added a hidden scroll text with the full credits for the team⁶.

Demo-scene interlude

On the demo side, the year 2000 was my #codefr/#demofr/#pixelfr year.

We had weekly competitions organized on these IRC channels, with random topics announced on the Friday evening, the idea being that on the Sunday we had to release the entries and then everybody would vote.

This was a very good way to learn how to design something in very limited time, and I guess it's more or less what people are doing nowadays with the Game Jams and other Ludum Dare.

There was two main kind of topics, the demos, and the games.

For the games I participated to only two, the first theme was "Elements".

It was really eye opening for me: Despite having worked for 10 years as a professional software developer, I managed to concentrate on all the wrong things in the wrong order, and in the end I had all the fluff (credits, high scores, intros, menus) but no actual game.


The second theme was "The Supermarket".

I changed the strategy and started by the code of the game, and only when it was working I added the fluff. The result is an absolutely ugly game that has the kind of addictive gameplay that would deserve a mobile phone port...

The concept is simple: You are a cashier, and you have to scan the products that pass on the rolling carpet in front of you. If the bar code is not visible you have to right click to turn the can until you see the code and then you scan it with the left click.

And it gets faster over time.


For the demos we had simple themes such as "Disco" or "Cracktro" and had to produce something based on the theme.

Here are mine:
The year 2000 was finished by an Oric demo, released in Holland at the ST News International Christmas Coding Convention (STNICCC 2000) in the C64 Revisited compo.


Based on the success of the STNICCC demo I managed to recruit other Oric enthusiasts and together we managed to build the first significant Oric demo, modestly titled Oric Giga Demo and to released it in July 2001 at the Very Important Party.


The demo was supposed to have a music, but unfortunately when we were on the party place it happened that our loading code was not working, so we had to use the standard DOS to load data: There was no room for the music anymore⁷.

Inter-projects

When V-Rally 2 was finally out of the box, in its various incarnation, came the time of the 'what next' question.

Some of the team members wanted to continue doing racing games, some other wanted to try something more creative.


Two teams were then created, one would work on what would become V-Rally 3, while the other team would be doing some brainstorming and try to came with some ideas (which would ultimately become Kya: Dark Lineage), both projects would be first developed for the PlayStation 2 and then eventually ported to the XBox and GameCube if necessary.


While the designers of both teams started their brainstorming, the programmers started working on what would be necessary to support the new platform, such as new libraries and new tools.

What I personally worked on was the libraries edFile and edText, and the tools Builder, ClickSafe, FontConv⁸, XlsXChange and TsdCompiler⁹. (All the 'colorful' logos coming up are from the original html documentations I wrote for the tools.)

ClickSafe was my answer to AlienBrain.

We needed an efficient way to handle revisions of our assets to avoid losing data, and our earlier attempts with AlienBrain were very not satisfying. The tool was slow to the point of being unusable¹⁰, so I designed my own asset versioning system.


It took some revisions before most of the quirks were ironed out, but at least it was a tool that everybody was able to use, because it was integrated in things that people were used to, such as as the windows explorer and the file dialogs.

The final version even had an external C API to hook it with our internal tools so they could directly check-out files.


The TsdCompiler was used to convert TSD files (Textual Scene Description) to a binary format optimized for the target platforms that could be loaded into memory as one single big bloc of data instead of requiring hundreds of small allocations.


The Builder started as a request from the V-Rally 3 team who wanted to start clean on their production pipeline.

Originally called MakeBank, it started as a simple parser for a text file format containing a list of resources to pack together in a big file called Bank.

Soon after, the feature requests were piling:
Would it be possible to have a list of optional files to add depending if we are in debug or release mode?
Could we have different alignment values for the data depending of the platform?
Could we have some automated tests to check that the file size does not get too large?
Could we have a command to chain the generation of multiple files so we can build all levels in one single call?
Would be nice to have a menu to select which level to build...
etc... etc... etc...

In the end the Builder ended up as a mix involving GFA Basic language syntax, BAT file type scoping, C preprocessor compatibility, binary file generation, registry reading and writing, speech synthesis, ... basically a Turing complete languages with enough quirks to turn a Perl programmer dizzy!

XlsXchange was used for the game localization. All the text entries would be edited in Excel files, and the tool would then extract the data from the sheets¹¹ and generate optimized binary files for each language, and some header files so the programmers could access directly some strings by using defines.


This tool was used for both V-Rally 3 and Kya.

So, in the end, I did not really code anything directly in V-Rally 3, the only contribution was what I did in the tool side and in the libraries I worked on.

On Kya on the other hand I started as one of the game programmers and wrote a good part of the menu system, text rendering, loading and saving code, and a significant part of the tech used for the asynchronous loading of levels.


I was also asked to work on a gameplay feature called The Cloud, but I refused: I said to my lead that I thought it was a stupid idea, that it looked good on paper but that it will be impossible to make it work with the multiple gameplay elements we already had in the game.

Saying that this impacted my relationship with the project lead would be an understatement, but in the end another programmer got the task, he implemented it as good as he could possibly had made it, and after a week of testing by the lead designer the whole code was thrown out.


I ended up in the Tech Team, working only on tools and libraries, which was fine with me: I had decided that I hated working with designers and other people who only know what they don't want when you show them what they actually asked you.

Tech team

For years the game developers had complained about the Tech Team, that it was too slow to release new versions of Twilight II (Eden's World Builder tool), or that their code was slow and inefficient, or that they did not tolerate criticism... so joining them was not as easy as just moving one's desk.


Truth be told, retrospectively speaking, Twilight II is probably one of the best designed internal tools I've seen during my career in the video games. Sure it had issues, but the core was solid, it had many interesting ideas, it was very flexible too.

The worse part was the time it took to build and deploy a new version, and indeed some of the code was not as fast as it could have been; but if we had all worked together to address these issues instead of staying in our ivory towers¹², perhaps a number of things would have turned differently.

And just to be clear: No I did not work on Twilight II, I'm just doing a public mea-culpa.

Infidelities

From 2000 to 2002, James Bond would have been proud of me.

Most people don't know about what I'm now writing, so I will not tell who else was involved. Feel free to come out if you feel like it!

In 2000 I was asked to discretely work with Virtools to evaluate how feasible would be the port of their Nemo engine to the Dreamcast.

In 2001 I worked in the position of Technical Director when we were trying to build Chimæra Games¹³.

We negotiated a free commercial license of Renderware, and built a prototype of Flint O’Connor and the Jewel of Halin.



Of course we did all this work just in time to see the Internet Bubble to explode.

Suddenly all our contacts got scared of the video game industry.

We had to drop the project and join the ranks.


Another company in Lyon, Arkane Studio¹⁴, was busy working on their epic role playing game: Arx Fatalis.

At the time they were unfortunately under-staffed, so the progress was not as fast as they hoped.

Trivia: The 'Special thanks to Mike Pointier' in Arx Fatalis credits is not only for the week end I spent helping profiling and analyzing the code. It was also for ClickSafe.
So far ClickSafe had only been used inside Eden, but there was some talks to perhaps make it available for the other's members of the Lyon Game association. The only problem was that we did not know if it would work on different set-ups.

I spent a number of weeks working on changes inside ClickSafe to make sure it would work on all types of servers, independently of the accuracy of the native time stamps, domain names, permissions, etc... and then tested from time to time at Arkane if the changes worked.

I'm not sure if they ultimately used it or not, but at least it was set-up correctly.

Back to paradize

V-Rally 3 was finally released in 2002, so we all concentrated on trying to get Kya finished, which for me involved destroying¹⁵ a significant number of PlayStation 2 TOOL devkits while working on the asynchronous loading code.

In 2002, the Defence-Force team was back at the VIP party, with an even larger Oric demo called Quintessential: More people, more graphics, and this time we finally had sound!


We were on the roll, so we decided to start a new demo immediately, with even more people.

Not surprisingly, what applies to video games also applies to demo making: More people means more organizational headaches, more human interactions and more bugs.

We presented our demo at the State of the Art demo party in December 2002: It crashed after 30 seconds, stuck on a ear piercing note.

After some talks and diplomacy we managed to present a remastered (and debugged) version of Barbitoric the next month at the Alternative Party 2003 in Helsinki.


Kya: Dark Lineage was finally released in 2003 on PlayStation 2, about at the same time as the GameCube, XBox and PC versions of V-Rally 3.

The two teams started to brainstorm on what would be their next games, and after quite many back-and-forth and other dead-ends involving deals with multiple publishers, discussions about original IPs and existing licenses, they finally started to work on Test Drive Unlimited and Alone in the Dark, both games to be released for PlayStation 3, XBox 360 and PC.


I basically spent the rest of my time at Eden Games working on the tech and tools used by these two games, such as porting the libraries to the new systems, upgrading the tools and adding new features.


With the next gen development budgets exploding, Eden did manage to work on some smaller projects reusing the older tech, so we helped them as well.

One such example is Titeuf Méga Compet released on PlayStation 2 and GameBoy.


I guess it's all there is to say about the software I worked on at Eden Games.

All during 2003 and 2004 I continued releasing Oric productions, games, demos and tools.

UlaPaint is a painting program which was never officially released, but I had some artists beta-testing it.


4K Kong was my entry to the 2003 Minigame Compo, and ranked at the 8th position (on a total of 63 games).


Cyclotron was my entry to the 2004 Minigame Compo, and ranked at the 6th position (on a total of 42 games).


During the summer 2004, I visited some friends in Norway and finished there my Buggy Boy demo which I later presented in the compo at the Little Computer People party in Sweden.


And I guess that's all I managed to dig out!

Both Test Drive Unlimited and Alone in The Dark were released years after I left the company¹⁶.

In may 2005 I moved to Norway and joined Funcom to work on the tools for Age of Conan: Hyborian Adventures.

But that is another story.

---