Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

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

By - | Views: 21,349
Hi people!

A new Cheese Talks article just went live!

This time, I'm looking back at what I learned from porting Day of the Tentacle Remastered to Linux (see our previous GamingOnLinux coverage here).

image

In addition to my own thoughts, the article includes insights from a number of other Linux game porters including Leszek Godlewski (Painkiller Hell & Damnation, Deadfall Adventures), Ryan "icculus" Gordon (StarBreak, Left 4 Dead 2, Unreal Tournament 2004, Another World, Cogs, Goat Simulator), David Gow (Keen Dreams, Multiwinia), Ethan Lee (Salt & Sanctuary, Hiden in Plain Sight, HackNet, Waveform, Dust: An Elysian Tail) and Aaron Melcher (Outland, La-Mulana, Hyper Light Drifter, Darkest Dungeon). Betweem them, they offer a great range of attitudes and approaches that support and provide counterpoint to my own experiences.

image

The whole article weighs in at a little over 11,000 words and covers what it's like to get started on a port, and what kind of ups, downs and betweens are likely to be found along the way. As a companion to the article, I've also been able to release the source code for the "coming soon" app that appeared for Linux users on Steam as the game got closer to release.

To whet your apetite and/or give a summary for those who aren't interested reading in the whole thing, here are some snippets.


QuoteMy personal connection to this game has expanded from being that of a player and an appreciator of its accomplishments to include that of a developer and in some respects a historian. I've had the opportunity not only to peek behind the curtain and experience a game I like from a new angle, but I've also been able to look back in time at a fascinating cross-section of LucasArts history. I've seen SCUMM code from the 80s written for Maniac Mansion (in one file, there's a lovely code comment saying there's a front row seat in hell for me if I edit it - I like to pretend that that's Ron Gilbert's "grumpy" persona yelling at me from across the decades), I've seen early 90s work from Day of the Tentacle's development, I've seen the "Remonkeyed" engine code written for the Monkey Island special editions, and I've seen Double Fine's work on adapting that for DotT's remastered edition.



QuoteFrom the outset, I was keenly aware that the codebase I'd be working in was of a scale beyond anything I had contributed to before. I'd been given the opportunity to review the codebase before signing a contract, but that really wasn't enough of a window to get the familiarity that I'd need to deliver a finished port - I'd need to be able to learn as I went without slowing myself down too much.

I set myself up a rough plan that would allow me to focus on achievable things while also exposing myself to more of the codebase as I went, which looked something like this:

* Set up my build environment ahead of time
* Work out-of-tree so that exploration and experimentation doesn't get committed
* Get the codebase to compile (stub out anything that looks like it needs rewriting)
* Sift back through looking for platform specific #if directives that might've been missed
* Look through all build scripts for any platform specific stuff that might've been missed
* Prepare an initial port commit and start working in-tree
* Rewrite any stubbed code
* Focus on fixing crashes/behavioural differences

By treating compilation as my initial goal, I'd be able to make forward progress with zero knowledge of the codebase - compiler errors would tell me where to look, and I'd learn bits and pieces about the project's structure as I went through doing superficial stuff like correcting case issues and making Linux specific copies of other platforms' #if directives.



QuoteSomething that was both expected and a surprise to realise was that my experiences of porting didn't really fall into the realm of what I would normally refer to as programming. In fact, reflecting on my experiences, I feel that it's probably fair to consider that it's a porter's goal to write as little code as possible.

All of the creative/design decisions around code structure, systems behaviour and dependencies are typically locked in place, and deviating from them means a port that's less likely to be maintained once it's completed.



Quote"The other really important thing to know when planning is if you're going to be working on the main branch of the game, or in a separate branch which will likely never be merged. You need to decide how much freedom you have to rewrite or refactor existing code, versus carefully changing only what is required. When in doubt, don't change things you don't have to, and document your changes well." - David Gow


image

QuoteThis may be a point of contention, as I do know some porters who don't agree with this outlook, but it seems important to me to make sure that I have lines of contact to developers who have previously worked on the project.

If there's a piece of code that needs to be understood before forward progress can be made, and that's either going to take two days to work through alone or twenty minutes' worth of conversation time, then it's pretty clear which approach is in the best interests of the project.



QuoteShortly after getting the Day of the Tentacle running (an early milestone), I had encountered an issue where audio cues were firing incorrectly. Advice from other developers who'd worked on the game was that it was most likely an interrupt loop that controlled the audio system being too far outside of its target 300ms interval, but nothing I tried on that front seemed to help. In an effort to track down the issue, I'd upgraded GCC to gain access to newer compiler flags that I hoped would help me narrow down my problem. In one late night flurry of bugfixes, I'd announced the problem solved by some unrelated commit and moved on.

When the time came to build the project inside the Steam Runtime, which just so happens to ship with GCC 4.8.1, the problem reared its unpleasant head again. After several days of slowly stepping through the game and scrutinising its behaviour, I discovered that somewhere between 4.8.5 and 4.9.2 (I couldn't spot anything useful in the GCC changelogs, and it didn't seem in the project's best interests to spend time digging out the relevant commit), the behaviour of the following C++ syntax, which is undefined in the language spec, had changed.

ptr += some_fuction(&ptr);

The ambiguity arises when this statement can be interpreted as either ptr = ptr + some_function(&ptr) or ptr = some_function(&ptr) + ptr. In the case we care about, the function modifies the value of ptr, and was used to calculate the length of data (say, an int representing how long an audio cue should last) in packed in memory. Instead of getting the correct memory address to read our value from, we end up reading partway through some other value and things spin wildly out of control from there. GCC's -Wsequence-point compiler flag is meant to help identify these kinds of problems, but it seems that the involvement of a function that manipulates the value of ptr confuses things a little.



QuoteOne friend and porter who would prefer to remain anonymous has passed on to me an aphorism that I found amusing: the more time spent on a bug, the smaller the fix. It's meant to be taken as a Murphy's Law type reassurance that tripping up on things that seem small in hindsight is normal, but it reflects some interesting characteristics of problem solving.

Small issues such as the one mentioned above are more easily overlooked, and the longer they wear on, the more frustrating they can become. With each hour, day, week or month that an elusive problem consumes, the number of more-obvious causes it could be hiding under dwindle. We learn about common problems like off-by-one errors and learn to look out for them, but until we've gotten that perspective, it's awfully difficult to spot them for what they are. Some things are just easier to see with experience, I think.



QuoteWhen it came time to move into testing, we encountered a fairly common and awkward situation. To allow access to testers who had normal subscriptions to the game on Steam, we would also be exposing Linux users to partial Steam configuration, which would cause the game to show up in their library and be listed as downloadable. Steam would "download" an empty folder and the first real indication that the player would get of something being wrong would be a misleading "missing executable" error. In other projects I've been involved with, this has generated support requests and grumbles from people assuming that developers don't know what they're doing.

Following the example set by some other porters (Ryan and Ethan in particular have been known to do this), I spent half an hour putting together a quick application that could be placed in the default non-beta branch and let Linux users know that the game was still coming soon.


image

QuoteRecognising that emotional and psychological state impact heavily on productivity, and making appropriate decisions around when to schedule breaks or recreational activities can help make sure that longer projects don't become overwhelming. In general, being aware of one's personal limits and reactions is important (see my game jam survival guide for some more thoughts on that) for being able to navigate and cope effectively with pressures and constraints.

Typically, I like to keep a rough window of time defined by best-case-scenario estimates and conservative not-so-good guesses for remaining work. When a relevant date (whether it's an external milestone or an internal personal goal) encroaches upon that window, I start adjusting my own expectations and make sure to communicate that upstream to whatever relevant contacts may need to know. Avoiding unpleasant surprises and being able to get the ball rolling on extensions or recalculated timeframes early can help make those (often unavoidable) situations easier to deal with and feel comfortable with.

To help keep track of progress and assist with triaging, I keep a log of thoughts, approaches and solutions for completed work as well as a list of known needed work. Typically this is more verbose and rambling than is appropriate for commit messages, but a bug tracker can be a good fit. Most of the time, I make do with a plain text file.

Having that kind of information available has been super helpful in keeping momentum and feel more comfortable stopping for sleep when in the middle of solving a problem.



Quote"Don't give up, always finish, ask for help, and don't let the work consume you. There can always be patches later. Learn what you can, check your assumptions, do better next time and don't beat yourself up too much. Sleep a little sometimes." - Ryan C. Gordon



QuoteAnybody who has worked on a big project will know that there's an adjustment period following the intensity of release. When working in teams, camaraderie and shared experience make this easier to work through. The ability to interact with communities and critics, to speak to and for one's work can be cathartic as well.

Many porters (particularly solo porters) don't have the same avenues for support. Porters generally are not authorised to speak on behalf of their employers, and without much creative input, the sense of personal investment can be diminished (to me, Day of the Tentacle is not, and never will be "my game"). The opportunities for working through "post release blues" are often very different for contractors.

For some projects that I've worked on, doing post-release support has been a nice way to wind down after a release, and doing volunteer outreach and tech support for Linux users that I've come across has been nice in that way. I can fully appreciate though, that this kind of direct community contact is not something that all porters are likely to find enjoyable or have permission to engage in.


image

QuoteFrom the work done by Matt, Oliver and the rest of the DotT Remastered team; through to Craig Derrick's and the Monkey Island Special Editions' teams' efforts; Tim, Dave and the original DotT team's work; and all the way back to Ron, Chip and Aric's work on the original SCUMM engine, the codebase I inherited for my port was well designed and (so much as these things can be) a delight to work with. I am very thankful to have been able to "work with" such talented people on well-made software.



This article and the Day of the Tentacle Remastered Linux port could not have been possible without the interest and support of Double Fine and the lovely people who work there. Being asked to work on the port was unexpected and I am humbled to have been invited to work on a game I love.

This has been a super huge journey for me, and I'm glad to be able to share my experiences with anybody who's interested.

Enjoy!


Update: I've also published a video with reflections on the game and my experiences of porting it.

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link
Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
Game developer, Linux helper person, and independent writer/interviewer.

Currently working on Winter's Wake, a first person text adventure thing and its engine Icicle. Also making a little bee themed base builder called Hive Time :)

I do more stuff than could ever fit into a bio.
See more from me
The comments on this article are closed.
21 comments
Page: «2/3»
  Go to:

wojtek88 Jul 24, 2016
@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!
tuubi Jul 24, 2016
View PC info
  • Supporter
Quoting: wojtek88If 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 Jul 25, 2016
Quoting: wojtek88@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.


Quoting: wojtek88There 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!
wojtek88 Jul 25, 2016
@Cheeseness great answer, thanks. Wish You many great ports.
@tuubi seems You also know a lot, like always.
All the best guys :)
Halifax Jul 25, 2016
Quoting: CheesenessI 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
Seegras Jul 25, 2016
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.
Mountain Man Jul 25, 2016
Quoting: STiATReally 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 Jul 26, 2016
Quoting: wojtek88@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 :)

Quoting: HalifaxChasecam 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 ^_^

Quoting: HalifaxEDIT:
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 :)
Cheeseness Jul 28, 2016
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
Halifax Jul 29, 2016
Quoting: Cheeseness
Quoting: wojtek88@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 :)

Quoting: HalifaxChasecam 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 ^_^

Quoting: HalifaxEDIT:
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 :-)

Quoting: CheesenessI 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
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.