Gossiping tongues have been saying that Enric and yourself had to carry a whole desktop computer to a meeting with a publisher to prove that one of your demos could run in real-time. True or false?
Definitely true. That was part of a prototype made back in the old times of PS2 that was based on a scene of "The Exorcist". We sent them a video of a possessed girl's head to Codemasters and they could not believe it was all running in real-time. So we took a plane, and just to make a point!
We set foot in their office, execute the demo, and… They were amazed. As a result, they asked us to make a horror game and the result was of course Clive Barker's Jericho, which was published for PC, PS3, and Xbox 360.
It's also been said that in an E3 videogame fair you were basically lying on the floor somewhere, hitting the keyboard to show a demo to a publisher.
Yeah, this time with a laptop! (laughs) It was back at the time when we were developing Scrapland. MSE home-base was located in a small house built in the Spanish First Republic. Old as hell but quite cozy.
Anyway, we spent the night before the presentation making sure the game was working as it should. But when we arrived in the E3, with 1 or 2 hours left to meet the suits, we had the great idea to test it out.
And it basically exploded! So after a 20 hours journey, we weren't going to be able to show them anything playable. No way. I had copied the whole project’s source code "just in case". Imagine both Enric and I looking for a socket like maniacs. When we found one, I basically threw myself to the floor to make it work.
And guess what? It was an issue caused by the change of time zone. At that moment, our engine checked the last modification time before deciding if an asset needs a compilation or not. So by moving from one time zone to another, some of the assets were trying to erroneously recompile. When I found the culprit I just made that code line go away. And it just- worked again!
Now that you mention the MercuryEngine, what would you say are the advances of having an engine of your own?
Well, I like it better to use an engine of our own because you really get to know how it works on the inside. That way you can blend it to your needs and adapt it to the game you're making. If your game takes place in the dark of the night, you can create an illumination system that solves all the problems that may come with it. With a generic engine, you can of course create a night environment but it won't likely be as good as something specially created for the game.
If your program over a generic engine, you'll find a lot of obstacles when fixing a complex problem. You get to change small stuff, but not it's architecture to make it behave like you want to. As much tools it might provide you, the architecture is what how it is. On the other hand, if you don't use those tools provided properly or use too many features, it dies. The performance goes down because you've introduced too many things in the game. Being given more edition flexibility usually ends up affecting performance negatively.
When used, you can't really know what issues are going to come up because it's incremental. Yeah, it might work just fine at the beginning of the development. But when adding more and more layers to it you end up saying "Hey, this is not going as well as it should". And by then, you've been working on that project for a whole year!
To sum up, in a generic engine the question is: "How can I do what I want to do in the engine?" In a self-made engine, the question is "What do I need to change to make the game". That changes the whole game development.
Did you always want to make games? What was your trigger to become a programmer?
I remember crystal clear having a Spectrum when I was more or less 9 years old. We had some games I went through a thousand times and one day I got bored. So, in the summer of 85 or 86, I started taking a glance at the Spectrum's manual. There were some instructions inside teaching how to plug it into the TV and what really caught my eye; a Basic command glossary. I also saw something that amazed me. Instructions on how to program a small drawing of a little spider. It taught how to use binary data to redefine a user's character for drawing that tiny spider wherever you wanted on the screen.
I was pretty attracted to it and started learning how it worked. I really liked to understand those lines of code looking at the glossary, those “print”, “let”, “for”, etc. Then I learned how to move the spider from one side to another. And yeah, that was mainly the trigger that made me really look things up, learn Basic's commands, and start doing things on my own!
The bright side of those 8 bits computer is that you power them on and it started on BASIC. As they didn't have a graphic interface, you used commands to run the games. It was pretty accessible to start programming back then. The very same way you load stuff using commands, you couldn't help to wonder what else could that thing do.
One year later, I started learning about the assembly language. If you guys wonder, it's a language used to write programs using the specific instruction set of a CPU, so you can read a CPU register, or add two numbers. Interestingly the Z80 didn’t have instructions to multiply numbers so you had to learn other ways of multiply numbers, for example using “shifts” and “adds”. But assembly is just a text representation of the machine code, so you need an assembler. I remember using GENS and MONS. The GENS assembler traduced them to machine code. The funny thing is that you had to save the program into a cassette tape every time before running them because it is easy to hang the CPU and lose your changes.
BASIC is a more abstract layer added to it. Instead of using CPU instructions, you write programs using more complex commands that the BASIC's interpreter will execute using lots of CPU instructions. That way you can write programs easier but at the cost of performance. Nowadays, there are also compilers that generate optimized machine code that is usually good enough for most things. In fact, if you wanted to use assembly for a game like today’s, it would probably take you half your life to program it.
Nowadays, there is no constant need to code in assembly, but it can surely help you sometimes! For example, we have done SIMD optimizations in the video decoder used in a game as recent as Spacelords. Or in the game we made for N-Gage called Zombies, the rasterizer code (which draws texture-mapped walls and floors) was run by the CPU, so it takes most of the cycles. I remember doing all kinds of assembly optimizations and old school tricks like unrolling loops or calculating the texture projection every n pixels. All I could come up with to make it work better. And we almost double our framerate!
Anyway, although writing code in assembly language may not be essential nowadays, understanding it is still very useful. You never know when you’ll need to debug a memory stomp caused by a nasty multi-threading bug.
[To be continued…]