Who am I?
Hi! I'm Luis Rodero, and I'm the target of all nagging and the shoulder to cry on when everything goes to hell. In other words I'm the tools programmer here at Frictional. I started back in 2006 (that's a while!) as a contributor; I made a few minor additions to the HPL Engine and then not-so-minor ones (like the OpenAL implementation that was added back in the day). I was hired for full-time work in 2008, when work on Amnesia had just started.I live in Seville, southern Spain, home of the Feria de Abril, the Serranito and the Springmmer season from Hell, which starts in April-ish and spans until late October and can easily melt a human brain if no countermeasures are taken. Since we all work remotely, I've actually tried quite a range of places to do my stuff, like every room in my previous apartment, study rooms at my former school, trains, planes... but nothing beats having a dedicated office space at home.
 |
| This here looks nicer than it usually does. |
Background
As a kid, I was really into finding out how stuff worked. Generally that involved ripping things open, much to my parents' disappointment of course. I also had an unhealthy attraction to videogames, which meant I vanished into thin air a lot only to be found at the nearest arcade in town. I got my first computer in the 80s and used to play games on it for countless hours; but it also came with these 'intro to BASIC programming' books that I thought were pretty cool, although I had no idea what I was doing when trying out the examples. |
| Beautiful and still working after more than 25 years (pic by Museo8Bits). |
For a few years I moved my focus away from programming and just played stuff on my Master System and a few years later on my Mega Drive, as I was quite a Sega fanboy (you could have killed past Luis by telling him a Sonic game had been released on a Nintendo console, go figure). But as time went on it wasn't fulfilling enough. That's when I targeted my father's PC (sorry dad). I still played a lot of stuff, but I never lost that itch for knowing how stuff worked, so that meant the PC was sent for technical support a load of times (again, sorry dad), but it also meant I learned a lot from trial and error. It wasn't until I found Alone In The Dark that I became determined to learn how a game was made. Man, that game hit me hard.
Before jumping head-first into learning how to program, I tried pretty much everything: drawing pixel art, frame by frame animation, composing music in trackers, 3D modelling... I also created a mods for Doom and Duke Nukem 3D, and, while I learned a lot and had a lot of fun, I realised that if I had a forte, it was not on the artistic side of the craft. So I started to focus on the technical side. I used to open any kind of file in a game with a text editor (and also with a hexeditor, but I didn't know that's what it was until quite a long time later), just to see how it looked. Most of the time it was illegible nonsense, but sometimes I found stuff I could read, and that's how I learned to change strings in EXE files. But this was clearly not enough, so one day I got my hands on a C programming book.
 |
| Not my best look, but the tentacles make up for that (wait, that sounded weird). |
Back in October 2004 (nearly ten years ago), I was still working on getting my degree in CS and looking for projects to work on for hobby, and then I checked this Thomas Grip guy out again, as after playing Fiend I knew he could pull off cool stuff. Turned out he was working on another game called Unbirth. That's when I approached him on the Unbirth forums. The rest is pretty easy to figure out. I had never seriously thought of doing this for a living, and now I feel I wouldn't be able to do anything other than this.
What do I do?
My main task here is to build and maintain the tools we use for creating content for our games. This means I'm in charge of the LevelEditor, ModelEditor, ParticleEditor and MaterialEditor programs. I made these pretty much from scratch, working on top of the HPL engine. This should make everything in the editors look just like it would do in a game powered by it. Occasionally I do bits of level scripting or other kinds of programming, but this is what I do most of the time.
The way the tools evolve is tightly coupled to how the engine changes. If, for instance, a new type of object is added to the map class in the engine, it would be weird if it didn't end up being added as a placeable object type in the LevelEditor. On top of that, we have changes to improve our workflows - for example, when an operation proves to be too time-consuming we look for ways to improve the editors to make that easier.
At the time of this writing, the tools are already huge, growing even bigger every day, but I can't just add features carelessly. One of the main goals of having custom tools is to make them suit our needs as much as possible, and that also implies paying a lot of attention to the user experience.
With this in mind, adding a new feature means that it should:
And where do these new features come from? Most of the time they are user requests, since when one is working with the tools, it might become obvious that some processes feel cumbersome and could be made simpler. Other requests come up from comparisons to other editors - 'hey, UDK has that feature, can we have it?' Also, if something reasonably simple can be done to save a user from having to alt-tab out of the editor to carry out an external task, that sounds like a good feature to me.
It begins with the description of the feature: what it should do and maybe a little overview on how. Then it's time for a preliminary design, which shouldn't be excessively detailed, since chances are we are gonna run into something at the time of integrating the feature into the system that we never took into account.
Once the first design is done, a first implementation is carried out. This should be done and put out to test as quickly as possible, to find flaws or possible improvements in the first stages.
After the first approach is tested, then any issues or requests in the feedback should be fixed. It's very unlikely that a feature turns out to be perfect or even acceptable before any checking (unless we are talking about really small ones), so here's where the feature is really shaped up.
Once the issues are fixed, it should be tested again. If no bugs or weird stuff pops up after that, then the feature makes it to the toolset. And that's how we make it!
Of course, the job doesn't come without problems. The main issue I face everyday is the fact that most of the stuff I have is based on code that's been there since we started work on Amnesia, when I had little to no idea on how things should be done. Since then, I've been working hard to migrate to a design that automates as much as possible and makes it easy to add or improve features. I'm kind of happy with what we have currently, but I know I can do way better than this.
Another issue is that we're dealing with software here. If something can break, it will break. And that will mean someone (most probably Marc) will come at me complaining about something broken. And then I'll have to stop what I'm doing at the time and move on to fixing stuff until that someone goes back to their normal happy state again.
So summing up, my workday revolves around keeping people happy (a noble cause, actually), and otherwise adding new stuff or improving the existing stuff. Hope you liked finding out more about what I do here, and see you in the next post on new tool features!
The way the tools evolve is tightly coupled to how the engine changes. If, for instance, a new type of object is added to the map class in the engine, it would be weird if it didn't end up being added as a placeable object type in the LevelEditor. On top of that, we have changes to improve our workflows - for example, when an operation proves to be too time-consuming we look for ways to improve the editors to make that easier.
At the time of this writing, the tools are already huge, growing even bigger every day, but I can't just add features carelessly. One of the main goals of having custom tools is to make them suit our needs as much as possible, and that also implies paying a lot of attention to the user experience.
With this in mind, adding a new feature means that it should:
- Work properly (would be weird to fail at this one)
- Be straightforward
- Be as quick to use as possible (the fewer clicks the better)
- Have as much visual feedback as possible (where this applies)
And where do these new features come from? Most of the time they are user requests, since when one is working with the tools, it might become obvious that some processes feel cumbersome and could be made simpler. Other requests come up from comparisons to other editors - 'hey, UDK has that feature, can we have it?' Also, if something reasonably simple can be done to save a user from having to alt-tab out of the editor to carry out an external task, that sounds like a good feature to me.
It begins with the description of the feature: what it should do and maybe a little overview on how. Then it's time for a preliminary design, which shouldn't be excessively detailed, since chances are we are gonna run into something at the time of integrating the feature into the system that we never took into account.
Once the first design is done, a first implementation is carried out. This should be done and put out to test as quickly as possible, to find flaws or possible improvements in the first stages.
After the first approach is tested, then any issues or requests in the feedback should be fixed. It's very unlikely that a feature turns out to be perfect or even acceptable before any checking (unless we are talking about really small ones), so here's where the feature is really shaped up.
Once the issues are fixed, it should be tested again. If no bugs or weird stuff pops up after that, then the feature makes it to the toolset. And that's how we make it!
 |
| Looking fishy if you ask me. |
Of course, the job doesn't come without problems. The main issue I face everyday is the fact that most of the stuff I have is based on code that's been there since we started work on Amnesia, when I had little to no idea on how things should be done. Since then, I've been working hard to migrate to a design that automates as much as possible and makes it easy to add or improve features. I'm kind of happy with what we have currently, but I know I can do way better than this.
Another issue is that we're dealing with software here. If something can break, it will break. And that will mean someone (most probably Marc) will come at me complaining about something broken. And then I'll have to stop what I'm doing at the time and move on to fixing stuff until that someone goes back to their normal happy state again.
So summing up, my workday revolves around keeping people happy (a noble cause, actually), and otherwise adding new stuff or improving the existing stuff. Hope you liked finding out more about what I do here, and see you in the next post on new tool features!
0 nhận xét:
Đăng nhận xét