Cheese Talks: Porting Games to Linux & Day of the Tentacle

Really cool is that one to read, mentioned in the original article (I seem to have missed it):

https://icculus.org/~icculus/dotplan/SeriousSam-CHANGELOG.txt

Daily log updates of the SeriousSam port of Ryan (icculus) Gordon, but writing not what has been done but what he's planning to do. Expect a lot of disappointment, and less "yyeeey" moments ;-).

Another interesting part is:
> Porting Is Not Software Development

porting is like fixing a huge mess of a bug with a code structure you don't like, but you have to focus on rewriting as little as possible. Which is the usual bugfix procedure (if fixing the bug of somebody else). Changing less means less possibilities to break. Had to experience that the hard way, "that's done bad, this could be done better" ending up in fixing what i "fixed" or "beautified".

I didn't port games yet, but I did port some more-or-less complex applications from Windows to Linux (codebase between 50.000 loc and 300.000 loc) knowing that very well, especially if you do know windows and are crazy enough starting to touch the windows implementation because you think you can do better with almost no effort than the windows guys who were paid for it. Never do that. Ever. Seriously. Get some fuel and a lighter, will be less pain and a faster end.

But really cool article to read, great that this one was shared. Thanks!


Last edited by STiAT on 24 July 2016 at 1:49 am UTC

Really cool is that one to read, mentioned in the original article (I seem to have missed it):

https://icculus.org/~icculus/dotplan/SeriousSam-CHANGELOG.txt

Daily log updates of the SeriousSam port of Ryan (icculus) Gordon, but writing not what has been done but what he's planning to do. Expect a lot of disappointment, and less "yyeeey" moments ;-).

That is a super cool piece of historic treasure, and I'm really happy that Ryan was able to share it.

For anybody who hasn't read it, it's probably important to read this introduction to get some extra context for that changelog.

I'd have loved to have shared mine, but my commit history was pretty boring and my daily log is mostly shorthand gibberish that wouldn't mean anything to anybody :D

porting is like fixing a huge mess of a bug with a code structure you don't like, but you have to focus on rewriting as little as possible. Which is the usual bugfix procedure (if fixing the bug of somebody else). Changing less means less possibilities to break. Had to experience that the hard way, "that's done bad, this could be done better" ending up in fixing what i "fixed" or "beautified".

This is very true, although I find that it's not necessarily that things were "bad", but often just that they weren't done in the way I like to do things. Since you don't get to see or be involved with the decision making processes, it's easy to assume that everybody was making bad decisions, when at the time, everybody was working hard and doing the best with what they had.

You're totally right about fixing up and making things pretty being a trap. If you start down that road, you'll be shaving yaks before you know it and will probably have broken other platforms along the way >_<

ptr += some_fuction(&ptr);

Heheh... Yeah, that's the thing about C and C++. They give smart people the ability to make exceedingly dumb decisions.

It's powerful how much low level access in a high level language you have to memory locations and variables, etc. But with great power comes great responsibility. And so many clever programmers are prone to making "cute" little syntactical shortcuts like this, even though they don't have to. And it just makes it harder to maintain... Even for Mr Clever himself, if/when he comes back a year later to regression test or change functionality / refactor.

I've learned over the years when I hit a spot of code where I'm starting to write "clever" code... After many many times of coming back later for some kind of change or upgrade and hitting a brick wall. Just literally staring at my own code until I spent more time than I wanted unraveling a tightly wrapped train of reasoning that was only clear in my head for a brief moment in time after a day or two of working with it originally..

I've learned, man. When I hit those spots now writing new code, I stop - oh no, I know what this is. Let's step back and take our time, lots of REM statements, long descriptive variable names. As a matter of fact, let's just think about what we name the variables as long as the code we're going to use them in...

That's one nice thing about open source code, many times it's been cleaned up internally just because you know it will be judged by other programmers. It's funny reading all the apologies from coders who decide to release their proprietary project on Github or something similar. They begin to realize people will now be looking at all the "shotgun code" and band-aides they left under the hood.

This is very true, although I find that it's not necessarily that things were "bad", but often just that they weren't done in the way I like to do things.

Ye well, that would be bad in my definition ;-). Everything not done the way I like it must be bad. I've bit of a Torvalds-Attitude there, which can be a huge issue.

This is very true, although I find that it's not necessarily that things were "bad", but often just that they weren't done in the way I like to do things.

Ye well, that would be bad in my definition ;-). Everything not done the way I like it must be bad. I've bit of a Torvalds-Attitude there, which can be a huge issue.

Nah, Linus occasionally getting inappropriately (and sometimes, just flat weirdly) upset about minor intra-Linux things is not equivalent to the quote. Every programmer who has to work on someone else's code can face this. Sometimes people think differently than you do. And if you have to make the code work now, you naturally would like it to be modeled around your style of logic, just so you can move forward easier.

There's usually 1,001 ways to go about any given task in coding, so this happens a lot.

But then there's the other side of that coin, sometimes you get code from someone else that is beautiful to look at, you want to copy its paradigms, learn from it. Improve your own style of coding by studying it.

Nice, thank you.

Very nice and detailed article but it didnt answer my basic noob questions , just some questions from a noob respective

Well I havent done any programming since like 15-20 years , so I wonder How hard is to get to the industry ? I mean what do you have to know? what I have to read? What programming languages you have to know? Are there any specific tools that you need for the porting? Do I need to know assembly ? Physics? Math? Gaming Engines? What compiler to use? etc etc.... PANIC MODE!!!

For me is like an endless road of knowledge , tools and information that I would just simply give up.
I would love to hear how you started with all these.

Heheh... Yeah, that's the thing about C and C++. They give smart people the ability to make exceedingly dumb decisions.

Ha ha, I know right. "Enough rope to hang yourself."

At the end of the day, you have to accept that people are typically working towards making sure that stuff works rather than stuff that specifically adheres to spec. Not a lot of programmers have complete awareness of what results in undefined behaviour, and certain (*cough cough*) compilers don't bother to highlight that too. It's easy to end up with a "this is what works for me" picture of things if out-of-spec code just happens to behave the same on every compiler and platform you usually work with.

I overlooked that line myself so many times ^_^

I've learned, man. When I hit those spots now writing new code, I stop - oh no, I know what this is. Let's step back and take our time, lots of REM statements, long descriptive variable names. As a matter of fact, let's just think about what we name the variables as long as the code we're going to use them in...

That's a good way to be. It's crazy to me that people seem to forget that 3rd generation languages exist to make things easier to read and work with. There's not much value at all in the fancy code that some people use to make themselves feel cool - the optimiser is only going to rewrite it anyway.

That's one nice thing about open source code, many times it's been cleaned up internally just because you know it will be judged by other programmers. It's funny reading all the apologies from coders who decide to release their proprietary project on Github or something similar. They begin to realize people will now be looking at all the "shotgun code" and band-aides they left under the hood.

I feel like that's normal though - you sort of need more eyes and more time to mature (which in my experience most proprietary projects don't get because people only get put where the money is - in new features or new projects). Everybody's code is awful until it's been worked over a few times.

There's usually 1,001 ways to go about any given task in coding, so this happens a lot.

But then there's the other side of that coin, sometimes you get code from someone else that is beautiful to look at, you want to copy its paradigms, learn from it. Improve your own style of coding by studying it.

Well said!

Very nice and detailed article but it didnt answer my basic noob questions , just some questions from a noob respective

Alrighty, let's take a look at these!

Well I havent done any programming since like 15-20 years , so I wonder How hard is to get to the industry ?

So far as porting goes, I've never chased a port, so I have no idea.

I've been an active and prominent member of the Double Fine community and have been running community events for years. I've also helped out with a few Linux issues here and there, and I think that that close proximity/high visibility as a cool Linux user who does stuff played a big role in me being offered the job.

In addition to the community work and general Linux help I'd given Double Fine contributing to me landing the port, I think some of the other developers I'd worked with over the years had put in a good word for me here and there (and vice versa). It's not uncommon for me to hear from one developer I've helped that they talked to someone who had nice things to say about me at E3 or GDC or PAX or where ever.

Maybe that's what it takes to break into the market - build meaningful relationships with people over half a decade and consistently demonstrate enthusiasm and ability. If that's the case, then that's not a good path - that's a lot of unpaid work right there.

I mean what do you have to know? what I have to read? What programming languages you have to know?

I'm not sure - I've never really read anything about porting before and leaned heavily on my own experience as a Linux based game developer and awareness of what porter friends have gone through.

The only language you really need to know is the language that the game you're porting was written in.

Are there any specific tools that you need for the porting? Do I need to know assembly ? Physics? Math? Gaming Engines? What compiler to use? etc etc.... PANIC MODE!!!

I'd say it depends on the project. I didn't touch do assembly with DotT. I didn't really touch any game code since that's all abstracted out from the platform specific code that I spent most of my time on.

For compilers, GCC and Clang are probably your best bet (but again, depends on the project). I did DotT's Linux builds with GCC, but also built the game with Clang. Building in multiple compilers is never a bad thing and can sometimes reveal stuff you might not have noticed.

If the game's written in a generic engine that you can get source for, definitely chase up that. If not, then you're as on your own as you would be with a game that was developed using a custom engine. You're not making a game, so to me, there doesn't seem to be much value in knowing how to use the engine to create a game - you're only adapting stuff that other people have made.

Physics and maths skills are good to have (I don't have these and wish I did), but I think in general, you're not likely to come across any of that kind of code that is platform specific. More important than those skills is the ability to read, comprehend, research and learn on the fly. It's less about what you know and how quickly you can find stuff if that makes sense? Programming's like that in general though IMO.

This quote from the super insightful David Gow is definitely worth taking onboard, I think:

Don't worry too much about having to know everything going in — not every port requires a knowledge of everything, and every port will involve learning a whole bunch of new things, be they languages or APIs or version control systems. Also, don't be afraid of asking for help — every porter I've met has been really friendly, and will no doubt be more than happy to answer questions, or give advice.

For me is like an endless road of knowledge , tools and information that I would just simply give up.
I would love to hear how you started with all these.

I feel like there are lots of different valid approaches here, and that because of my background my side-activities, I don't I make for a good example (I honestly don't think any one person can, and that's something I hope is reflected in the various porters' quotes that I've included in the article).

I have a mostly comprehensive list of Stuff I've Done over here, but it's probably difficult to put into a chronology. Here's a quick rundown on the stuff that seems relevant.


I first started programming in the 80s. My family got an Amiga 500 when I was 7 or 8, and my Dad and I learned to program together by copying examples out of computer magazines. Mostly I messed around with AmigaBASIC and AMOS at the time.

Later, when I got the laptop mentioned at the beginning of the article, I made a bunch of dumb stuff with QBASIC, VisualBasic and some other junk that I can't remember (maybe some Delphi thing? I have no idea).

I continued doing programming at school, but didn't really learn anything I hadn't already discovered on my own. I picked up Pascal, Python, Java and C/C++ along the way.

In the nearly 2000s, I put together a small team and started working on some Half-Life 1 mods. I didn't do much programming on those and mostly focused on game design and asset creation. It was around this time that I decided that making games was something I wanted to do (note, porting isn't making games).

I switched to Linux a little while after that and started contributing to Neverball in my spare time. The goal was to use my day jobs (I did pizza delivery, retail, helpdesk, sysadmin, app dev and embedded dev) to get stable enough to start my own game dev studio, but that never really happened.

Around 2011, I started being more visibly active in Linux gaming circles, started tracking Humble stats and helped form the initial SteamLUG community that grew out of the long running SPUF Linux thread. I was also prominent in the Desura community and became a Desurium contributor when the client was open sourced. I feel that all this sort of platform advocacy and community engagement stuff has been helpful in having other developers take me seriously.

From this point on, I started making myself available to assist developers who were interested in supporting Linux as a favour. I never really thought much of it at the time and never kept records. Mostly I was just giving reassurance, offering advice on how to package things and helping identify bugs and stuff. I think between then and now, I've helped in that manner with maybe 50 titles?

Around this time, my friend flibitijibibo (Ethan Lee) did his first port, and ended up getting working with Humble to help cope with the increased demand for Linux support that their "must be cross platform" requirement drove. Linux porters seemed to be in high demand (everybody was busy). I was approached to do some Linux ports, but turned them down (some trivia: Bohemia were among these - I'm really happy to know they finally got Arma3 onto Linux!). They weren't titles I was interested in, and I wanted to make my own games, not other people's.

I started making my own games again in earnest in 2012 after recovering from a repetitive strain injury. I ended up in a small team working on a game for the first 7DFPS. From that point forward, I have had at least one game development project on the go at any given point in time.

When Double Fine launched their crowdfunding campaign for what would eventually become Broken Age, I became active within their community, organising backer meetups, community development projects and taking over Game Club when it became too much for DF's Greg Rice to run on his own. I was motivated to do all this stuff by the company's enthusiasm for and commitment to Linux (and because their games were cool). As time wore on, I eventually made friends with a bunch of people who work there and was asked to help do informal pre-release Linux testing on a few projects.

When I heard that a simultaneous release for DotT Remastered wouldn't be possible, I offered to help out in any way that would make it easier for them, and eventually negotiated to help with QA. Toward the end of March, I was offered the port, which coincided with timeframes I had for looking for contract work to boost my savings so that I could keep doing my own game dev. By the end of April we had agreed on contract terms, and I started work on May 1st (not including the time I spent looking over the code before signing the contract).


Hope that helps!

More important than those skills is the ability to read, comprehend, research and learn on the fly. It's less about what you know and how quickly you can find stuff if that makes sense? Programming's like that in general though IMO.

This is my experience exactly. I don't think I've ever done a project that didn't require learning something new. Be it a new API or framework or toolkit or a database system or whatever. And that's one part of why I like this job despite the stress and the unpredictability of being self-employed in this field. I guess I get bored easily.

One thing that always gives me mixed feelings is the weird notion people have of this work (software design) being somehow glamorous or requiring some very specific and rare talent or genius, when the only thing that's absolutely required is some creativity and masochistic levels of patience.

A fantastic read, Cheese. Can't wait to play the game!

@Cheeseness I have to say I enjoyed a lot this article. But I miss one thing - it did cover technical part of the porting job, but did not cover business part.
If it is not a secret and you're not obligated to keep it to yourself - could you tell if the project was a "once paid" job or do you have some profit of the income that each copy gives? And if the contract you have in this game is typical or does it differ from project to project?
What's more - assuming that you have a profit from each copy of the game - what part of income does go to you?

There is a reason why I ask - I wonder if buying games on sales have influence on a money you (as a single porter) get or does it influence publisher influence (which of course has an impact on a money that publisher can divide between developers, but does not influence your income, because you decide if you take the job with given money or you don't).

Anyway, great article!

If it is not a secret and you're not obligated to keep it to yourself - could you tell if the project was a "once paid" job or do you have some profit of the income that each copy gives? And if the contract you have in this game is typical or does it differ from project to project?

Cheese said elsewhere that he doesn't get a cut of any sales and that this is pretty much the norm for third party porting contracts. It's different for companies like Feral and Aspyr probably because they also publish, market and support their ports.

@Cheeseness I have to say I enjoyed a lot this article. But I miss one thing - it did cover technical part of the porting job, but did not cover business part.
If it is not a secret and you're not obligated to keep it to yourself - could you tell if the project was a "once paid" job or do you have some profit of the income that each copy gives? And if the contract you have in this game is typical or does it differ from project to project?
What's more - assuming that you have a profit from each copy of the game - what part of income does go to you?

As tuubi mentions, it's my understanding (this was my first ) that the majority of porting contractors abide by the the kind of work-for-hire arrangements you'd see for contracted work in any other area/industry.

That said, I do know porters who have worked for "a cut", and/or for free (I admire the enthusiasm and passion behind doing stuff for free, and respect the work, but I worry a little about what that means for maintainability and market perceptions of skilled labour in this area). The game dev industry in general, and the indie dev scene in particular can be pretty informal at times so I imagine that things can vary greatly. None of the helping-out-other-devs-who-want-to-support-Linux type stuff I've done prior to DotT involved contracts or remuneration at all.

The type of work that Feral and Aspyr do is in a different sort of category. Rather than being contractors who're paid by a game's original developer or publisher to do the port and move on, they effectively become the Linux publisher for the games they port and support/maintain them with a degree of independence.

There is a reason why I ask - I wonder if buying games on sales have influence on a money you (as a single porter) get or does it influence publisher influence (which of course has an impact on a money that publisher can divide between developers, but does not influence your income, because you decide if you take the job with given money or you don't).

The number of Linux sales DotT generates doesn't impact on me directly.

I would say that the number of sales and amount of revenue (which can paint very different pictures thanks to the kind of discount culture at work today) is likely to impact on how a developer values Linux support and will indirectly impact on whether they're likely to pursue Linux support in the future and influence whether they are interested in growing internal Linux skills and/or hiring external porters.

As you mention, publishers can play a big role in this. Many developers don't have the ability to fund Linux ports of games where the funding publishers aren't interested in throwing money at that (which may be why some games don't end up with simultaneous Linux releases when devs resort to scraping together resources to fund it on their own), and some publishing agreements can even prevent developers from self-publishing their game on certain/additional platforms.

Hope that's helpful!

@Cheeseness great answer, thanks. Wish You many great ports.
@tuubi seems You also know a lot, like always.
All the best guys :)

I have a mostly comprehensive list of Stuff I've Done over here, but it's probably difficult to put into a chronology. Here's a quick rundown on the stuff that seems relevant.


I first started programming in the 80s. My family got an Amiga 500 when I was 7 or 8, and my Dad and I learned to program together by copying examples out of computer magazines. Mostly I messed around with AmigaBASIC and AMOS at the time.

Later, when I got the laptop mentioned at the beginning of the article, I made a bunch of dumb stuff with QBASIC, VisualBasic and some other junk that I can't remember (maybe some Delphi thing? I have no idea).

I continued doing programming at school, but didn't really learn anything I hadn't already discovered on my own. I picked up Pascal, Python, Java and C/C++ along the way.

In the nearly 2000s, I put together a small team and started working on some Half-Life 1 mods. I didn't do much programming on those and mostly focused on game design and asset creation. It was around this time that I decided that making games was something I wanted to do (note, porting isn't making games).

I switched to Linux a little while after that and started contributing to Neverball in my spare time. The goal was to use my day jobs (I did pizza delivery, retail, helpdesk, sysadmin, app dev and embedded dev) to get stable enough to start my own game dev studio, but that never really happened.

Around 2011, I started being more visibly active in Linux gaming circles, started tracking Humble stats and helped form the initial SteamLUG community that grew out of the long running SPUF Linux thread. I was also prominent in the Desura community and became a Desurium contributor when the client was open sourced. I feel that all this sort of platform advocacy and community engagement stuff has been helpful in having other developers take me seriously.

From this point on, I started making myself available to assist developers who were interested in supporting Linux as a favour. I never really thought much of it at the time and never kept records. Mostly I was just giving reassurance, offering advice on how to package things and helping identify bugs and stuff. I think between then and now, I've helped in that manner with maybe 50 titles?

Around this time, my friend flibitijibibo (Ethan Lee) did his first port, and ended up getting working with Humble to help cope with the increased demand for Linux support that their "must be cross platform" requirement drove. Linux porters seemed to be in high demand (everybody was busy). I was approached to do some Linux ports, but turned them down (some trivia: Bohemia were among these - I'm really happy to know they finally got Arma3 onto Linux!). They weren't titles I was interested in, and I wanted to make my own games, not other people's.

I started making my own games again in earnest in 2012 after recovering from a repetitive strain injury. I ended up in a small team working on a game for the first 7DFPS. From that point forward, I have had at least one game development project on the go at any given point in time.

When Double Fine launched their crowdfunding campaign for what would eventually become Broken Age, I became active within their community, organising backer meetups, community development projects and taking over Game Club when it became too much for DF's Greg Rice to run on his own. I was motivated to do all this stuff by the company's enthusiasm for and commitment to Linux (and because their games were cool). As time wore on, I eventually made friends with a bunch of people who work there and was asked to help do informal pre-release Linux testing on a few projects.

When I heard that a simultaneous release for DotT Remastered wouldn't be possible, I offered to help out in any way that would make it easier for them, and eventually negotiated to help with QA. Toward the end of March, I was offered the port, which coincided with timeframes I had for looking for contract work to boost my savings so that I could keep doing my own game dev. By the end of April we had agreed on contract terms, and I started work on May 1st (not including the time I spent looking over the code before signing the contract).


Hope that helps!

Nice, you are a smart programmer living a fruitful life. I started out with CGI programming for ISP companies doing company websites back in the Day (90's) and moonlighted doing QuakeC mods for the original Quake. Chasecam 2 was my claim to fame back then. I made several mods, but Chasecam 2 got me 100's of emails per week from fans all over the world. I'm 99% sure, after watching it and recognizing all the boundary condition handlers I wrote, this is my mod in action:
https://www.youtube.com/watch?v=vyxV5RvFZLY

Boundary conditions, boundary conditions, boundary conditions. My sole mission with the mod was making 3rd person view work for the whole Quake game no matter what situation you were in. Back then, it was all new and mind blowing :-)

Then, I got a boring non gaming-related programming job. Now, I'm a "Scrum Master" - how lame is that?

EDIT:
To be clear, I'm not that good of a programmer - sometimes I can get on a roll. But I knew I would get eaten alive by smarter programmers if I tried to make it in the game industry. But I'm envious of you guys that are good enough to make it :-)


Last edited by Halifax on 26 July 2016 at 12:22 am UTC

Very much appreciated.

I dabbled in porting as well (you know, these things somebody open sources, and you realize it's all Win32-code? And even worse, thousands of buffer-overflows, off-by-one-errors and memory leaks. needless to say, I didn't get anywhere. Kudos if you can name the game involved ;)); plus some smaller console-oriented utilities.

Really cool is that one to read, mentioned in the original article (I seem to have missed it):

https://icculus.org/~icculus/dotplan/SeriousSam-CHANGELOG.txt

Daily log updates of the SeriousSam port of Ryan (icculus) Gordon, but writing not what has been done but what he's planning to do. Expect a lot of disappointment, and less "yyeeey" moments ;-).

Another interesting part is:
> Porting Is Not Software Development

porting is like fixing a huge mess of a bug with a code structure you don't like, but you have to focus on rewriting as little as possible. Which is the usual bugfix procedure (if fixing the bug of somebody else). Changing less means less possibilities to break. Had to experience that the hard way, "that's done bad, this could be done better" ending up in fixing what i "fixed" or "beautified".

I didn't port games yet, but I did port some more-or-less complex applications from Windows to Linux (codebase between 50.000 loc and 300.000 loc) knowing that very well, especially if you do know windows and are crazy enough starting to touch the windows implementation because you think you can do better with almost no effort than the windows guys who were paid for it. Never do that. Ever. Seriously. Get some fuel and a lighter, will be less pain and a faster end.

But really cool article to read, great that this one was shared. Thanks!

I've read that professional code is often messier and more poorly commented than open source code because unlike hobbyists and people coding in their spare time, professionals are paid to make things work, not to make it beautiful.

@Cheeseness great answer, thanks. Wish You many great ports.

I don't have any plans to pursue porting. If people I have interest in working with approach me, then I'll do what I can to help them out (like I did with DotT), but in general, porting isn't where I see my future :)

Chasecam 2 was my claim to fame back then. I made several mods, but Chasecam 2 got me 100's of emails per week from fans all over the world. I'm 99% sure, after watching it and recognizing all the boundary condition handlers I wrote, this is my mod in action:
https://www.youtube.com/watch?v=vyxV5RvFZLY

Boundary conditions, boundary conditions, boundary conditions. My sole mission with the mod was making 3rd person view work for the whole Quake game no matter what situation you were in. Back then, it was all new and mind blowing :-)

That's great! Keep a handle on it and maybe think about writing about what you accomplished. That kind of stuff fades over time and ends up being lost if nobody chronicles it.

My first publicly released thing was a HL1 mod. In hindsight, I guess there's not a lot that's noteworthy about it, but doing stuff and making stuff at the time was super empowering. I hope to someday have time to return to it and re-release it with a few bugfixes and Linux support - I owe a lot to that game ^_^

EDIT:
To be clear, I'm not that good of a programmer - sometimes I can get on a roll. But I knew I would get eaten alive by smarter programmers if I tried to make it in the game industry. But I'm envious of you guys that are good enough to make it :-)

Hey, you know, I think this goes for all of us. Everybody assumes that other people are better/smarter/more capable than they are, but from what I've experienced and read, it just isn't like that (there are lots of other people that've written cool stuff about "impostor syndrome" - don't let it disempower you!).

I don't think my skill had anything to do with me landing the DotT port, and I don't think it really had much to do with the game running and being received as well as it has been. I just had high visibility and enthusiasm at the right time, plus a little reputation from helping out others who needed it :)

For anybody who's still following along (or hasn't had time to read the article), I've also published a longplay of the game with some thoughts/reflections on the game.

View video on youtube.com

@Cheeseness great answer, thanks. Wish You many great ports.

I don't have any plans to pursue porting. If people I have interest in working with approach me, then I'll do what I can to help them out (like I did with DotT), but in general, porting isn't where I see my future :)

Chasecam 2 was my claim to fame back then. I made several mods, but Chasecam 2 got me 100's of emails per week from fans all over the world. I'm 99% sure, after watching it and recognizing all the boundary condition handlers I wrote, this is my mod in action:
https://www.youtube.com/watch?v=vyxV5RvFZLY

Boundary conditions, boundary conditions, boundary conditions. My sole mission with the mod was making 3rd person view work for the whole Quake game no matter what situation you were in. Back then, it was all new and mind blowing :-)

That's great! Keep a handle on it and maybe think about writing about what you accomplished. That kind of stuff fades over time and ends up being lost if nobody chronicles it.

My first publicly released thing was a HL1 mod. In hindsight, I guess there's not a lot that's noteworthy about it, but doing stuff and making stuff at the time was super empowering. I hope to someday have time to return to it and re-release it with a few bugfixes and Linux support - I owe a lot to that game ^_^

EDIT:
To be clear, I'm not that good of a programmer - sometimes I can get on a roll. But I knew I would get eaten alive by smarter programmers if I tried to make it in the game industry. But I'm envious of you guys that are good enough to make it :-)

Hey, you know, I think this goes for all of us. Everybody assumes that other people are better/smarter/more capable than they are, but from what I've experienced and read, it just isn't like that (there are lots of other people that've written cool stuff about "impostor syndrome" - don't let it disempower you!).

I don't think my skill had anything to do with me landing the DotT port, and I don't think it really had much to do with the game running and being received as well as it has been. I just had high visibility and enthusiasm at the right time, plus a little reputation from helping out others who needed it :)

LOL, I just bought DotT Remastered due to reading this post. I want to check out your port work and enjoy a classic game I never played originally! :-)

I'm not really a bad programmer. I was getting offers from a few gaming companies to come on board as a game programmer back in the 90's. But instead went with my dad to get into CGI and web programming on Linux C Apache driven servers back in the day, then branched off from there into GIS programming and then absolutely dominated a few private companies where my code became integral to those company's web presence.

"Imposter syndrome" is right. There was a period of about 12 years where I was absolutely sure smarter coders would come along at anytime and replace the web interfaces I'd made for a company's web site I'd put the most work into/my biggest contract, but that never happened.... I was sure it would, but it didn't.

And then the company decided to hire me on instead of keeping me as a consultant/freelance developer. They gave me a team of about 15 database and code engineers, and I was the one that finally replaced my old user interface (and all the backend) with a way better modernized solution. But I didn't write it, I just ran the meetings :-)

I hope to someday have time to return to it and re-release it with a few bugfixes and Linux support - I owe a lot to that game ^_^

I think you should, or write a new Indie game inspired by your mod that's all your own... That's the real empowering thing Notch Persson and Valve have given us, and now validated by the number of other Indies who've made it: the re-animated belief that a one-man indie team can make a game that competes for sales with the big AAA titles that cost as much as a Hollywood movie to make, now.


Last edited by Halifax on 29 July 2016 at 4:43 am UTC