software industry - where does the money come from?

[Gian_Yagami]

Maybe this is a bit out of topic. I am curious about software company like winrar or havok or anything else, how could they make money if user still could use winrar even there show message "please purchase..." or Havok when people know how physics simulated. Yes, knowledge is expensive but what if people already know it, did their income will lost? Since many people nowadays making tons of Software and one day, everything can be counted or process with a software so it's impossible to make new things of software.

[The_GTA]

My guess is that WinRAR lives from people that have used it for so long that they eventually have started making money and then pay off their WinRAR debt.

Edited January 21, 2018 by The_GTA

[Gian_Yagami]

My guess is that WinRAR lives from people that have used it for so long that they eventually have started making money and then pay off their WinRAR debt.

I think you right, there's a guy who asking the same question as me https://www.quora.com/How-does-WinRar-make-money-if-we-can-use-it-after-the-trial-is-over

and by the way I just found out that winrar belongs to individuals and not companies, Looks like he's okay about his income from winrar

 

And how about havok, I'll make this case clearer. How software company survived if their competitor product are free software?

[K^2]

I can talk about Havok a bit, as I've nearly ended up working there, and a lot of my work in game dev has had to do with animation and physics. First of all, you'd be surprised how little physics software engineers in game development companies know. I mean, yes, most of them know F = ma. At least a few in any decent company will know about Runge Kutta or Verlet, and be able to at least follow Wiki article to implement it. But you start talking about undetermined multipliers, and eyes start to glaze over. To implement a good physics engine, it's not enough to know basic physics you are trying to simulate. Unfortunately, computational physics comes with all kinds of limitations, and that means you usually need to know a lot more about physics, mathematics, and computer science than you need to simply understand the principles and make use of a physics engine.

 

In practice, to write a good physics engine, you should be comfortable with the entire course of Classical Mechanics, or at very least, understanding how constraints are introduced in a system described by its Lagrangian and Hamiltonian. You should also understand how to translate all of this into algorithms that are stable numerically. That's at least a course in Numerical Analysis on top of the Calculus and Differential Equations courses you needed for Classical Mechanics. The key topics here are numerical integration, including aforementioned Runge Kutta, and numerical linear algebra. Specifically, you end up with a lot of cases where you have to find inverses of nearly-singular matrices. If you skip on one or another, you end up with the common bugs of objects bouncing all over the place, until your entire simulation explodes. Finally, you have to know how to put all of this into code efficiently. Simulating a few objects is good and all, but you're usually talking about simulating thousands in a good engine, at least. This involves both the standard comp-sci tricks, like space partitions and bounding boxes, but also understanding compilers and SIMD capabilities at your disposal. I had a tab pretty much permanently opened on Intel Intrinsics Guide while working in game dev. Everything from quaternion algebra, to skinning, to some custom physics had to run through it to get the performance we wanted out of it. We ran on top of PhysX, but I had to dig inside PhysX code on occasion as well.

 

But that's not even the whole of it. What it really comes down to eventually is costs. For a small company, hiring a person who even can write code like this is often prohibitively expensive. If you can grab a free engine off the shelf, or pay for a reasonable license and hire two gameplay programmers instead, you'll jump at opportunity. For larger companies, the question is usually posed slightly differently, but it's still about cost. What large companies usually pay for with Havok is not so much the engine itself, but access to Havok's resources. Havok will work with companies like Bethesda, fine-tuning parts of the engine to fit their game. And that's a lot cheaper for Bethesda to do than have their own, internal physics team. And this is how it usually goes for almost any piece of middleware that's more or less successful.

[Gian_Yagami]

I can talk about Havok a bit, as I've nearly ended up working there, and a lot of my work in game dev has had to do with animation and physics. First of all, you'd be surprised how little physics software engineers in game development companies know. I mean, yes, most of them know F = ma. At least a few in any decent company will know about Runge Kutta or Verlet, and be able to at least follow Wiki article to implement it. But you start talking about undetermined multipliers, and eyes start to glaze over. To implement a good physics engine, it's not enough to know basic physics you are trying to simulate. Unfortunately, computational physics comes with all kinds of limitations, and that means you usually need to know a lot more about physics, mathematics, and computer science than you need to simply understand the principles and make use of a physics engine.

 

In practice, to write a good physics engine, you should be comfortable with the entire course of Classical Mechanics, or at very least, understanding how constraints are introduced in a system described by its Lagrangian and Hamiltonian. You should also understand how to translate all of this into algorithms that are stable numerically. That's at least a course in Numerical Analysis on top of the Calculus and Differential Equations courses you needed for Classical Mechanics. The key topics here are numerical integration, including aforementioned Runge Kutta, and numerical linear algebra. Specifically, you end up with a lot of cases where you have to find inverses of nearly-singular matrices. If you skip on one or another, you end up with the common bugs of objects bouncing all over the place, until your entire simulation explodes. Finally, you have to know how to put all of this into code efficiently. Simulating a few objects is good and all, but you're usually talking about simulating thousands in a good engine, at least. This involves both the standard comp-sci tricks, like space partitions and bounding boxes, but also understanding compilers and SIMD capabilities at your disposal. I had a tab pretty much permanently opened on Intel Intrinsics Guide while working in game dev. Everything from quaternion algebra, to skinning, to some custom physics had to run through it to get the performance we wanted out of it. We ran on top of PhysX, but I had to dig inside PhysX code on occasion as well.

 

But that's not even the whole of it. What it really comes down to eventually is costs. For a small company, hiring a person who even can write code like this is often prohibitively expensive. If you can grab a free engine off the shelf, or pay for a reasonable license and hire two gameplay programmers instead, you'll jump at opportunity. For larger companies, the question is usually posed slightly differently, but it's still about cost. What large companies usually pay for with Havok is not so much the engine itself, but access to Havok's resources. Havok will work with companies like Bethesda, fine-tuning parts of the engine to fit their game. And that's a lot cheaper for Bethesda to do than have their own, internal physics team. And this is how it usually goes for almost any piece of middleware that's more or less successful.

Thank you for sharing, It's meaningful for me. Now I know how software industries survive and I have no worries anymore if I become one of their part.