Programming thread

How common it is for indie game developers to know both programming languages and 3D modeling or some other skill like OST composition, story writing and such?
A lot of "indie game dev"s are artfags above all else. It's rare they have a background in computing. That's why we have shit like GameMaker Studio
 
How common it is for indie game developers to know both programming languages and 3D modeling or some other skill like OST composition, story writing and such?
Hard to pin point exactly. Outside rogue-likes, I would assume most successful indie devs are primarily skilled in other things than programming.
Like TobyFox was primarily musician. Others like ConcernedApe develop other skills as he was making Stardew.
Scott Cawthon is animator and writer.

But there are also indie teams, and some outsource parts of games for contractors. Or even buy pre-made assets.
 
Arduino won't really teach you much.
I mean if you have an interest in electronics it might be useful. Though when it comes to computers I don't know.
I would assume most successful indie devs are primarily skilled in other things than programming.
A lot of "indie game dev"s are artfags above all else. It's rare they have a background in computing.
So a one-man game dev would be something rare it seems.
 
So a one-man game dev would be something rare it seems.
Making games is hard. It's interdisciplinary endeavor. If you don't have strong vision that can carry game that would otherwise be lacking in some aspects. It is just insane amount of effort to be able to make everything by yourself.
Often it's just easier and more effective to use your primary skills to earn money and pay for things you need.
 
Making games is hard. It's interdisciplinary endeavor. If you don't have strong vision that can carry game that would otherwise be lacking in some aspects. It is just insane amount of effort to be able to make everything by yourself.
Often it's just easier and more effective to use your primary skills to earn money and pay for things you need.
Perhaps that's the reason why we have fuck-ups like Alex Mahan and Jason Hall? Do you think they underestimated the amount of work they would have in developing their respective games?
 
Perhaps that's the reason why we have fuck-ups like Alex Mahan and Jason Hall? Do you think they underestimated the amount of work they would have in developing their respective games?
Nah, those are just lazy bums. YanDev had enough support to pay for what he needed, and get twice as much for free from volunteers.
Jason has competent artist gf/bf and worked with competent musician.
In both cases they failed on their primary responsibility of being programmers.

it's not uncommon
I would say it happens, but given the scale of how many try it's rather uncommon to be successful. At least in being financially secure sense.
 
  • Like
Reactions: Blade of Grass
One thing I never see talked about online when it comes to dependencies is the cost of using dependencies. You often hear about the cost of "reinventing the wheel" and the apparent dangers thereof, but never anything about the cost of dependencies. I'll illustrate with an example, you want to parse XML so you import an XML parser library that has 10 other dependencies, those dependencies have dependencies etc, this is potentially a super-linear curve that grows with the number of dependencies (e.g. any fucking Rust library). That's the cost in terms of compile time but the worst comes for implementation code using a library. Any sufficiently advanced library meant to handle a real workload is bound to handle every reasonable edge case that users might encounter, so the complexity of a library for general purpose use will be at least a magnitude greater than hand-written code that serves a single purpose for a single user. So you wanted to parse some XML files, maybe you only needed a subset of XML, maybe not, but what you got was 100,000+ lines of code you now depend on for parsing XML and a complex API boundary written by some do-it-for-free GitHub janny. So what did you really gain from using the dependency? Nothing, in fact it's added negative value.
 
I'll illustrate with an example, you want to parse XML so you import an XML parser library
(...)
So what did you really gain from using the dependency? Nothing, in fact it's added negative value.
This isn't a good example. Speaking from experience, there's a lot of wheel-reinventing you'd have to do to get an XML parser that's halfway usable, even assuming the input is fully standards-compliant well-formed XML. Unless your task is simple enough that you could replace it with a regex ("I'm looking for the contents of the one and only <price> tag in this XML"), this is exactly the sort of thing where you would want a library.
 
I'll illustrate with an example, you want to parse XML so you import an XML parser library that has 10 other dependencies, those dependencies have dependencies etc, this is potentially a super-linear curve that grows with the number of dependencies (e.g. any fucking Rust library).
With sympathy to your point, libexpat, which is the gold standard of C XML parser libraries, has zero additional dependencies.

But yes, by all means, if your problem case can be solved by simpler methods (eg. grep, sed, awk, handrolled parser, whatever), use those methods!
 
Making games is hard. It's interdisciplinary endeavor. If you don't have strong vision that can carry game that would otherwise be lacking in some aspects. It is just insane amount of effort to be able to make everything by yourself.
Often it's just easier and more effective to use your primary skills to earn money and pay for things you need.
Doesnt really matter how strong your vision is if people wont give you the tools to catch a fish on your own and then gaslight you about the concept of fishing.
 
Doesnt really matter how strong your vision is if people wont give you the tools to catch a fish on your own and then gaslight you about the concept of fishing.
Man, I felt that. I get the same feeling when I ask for advice to solve that "hallway chirp" that people complain about in my apartment, and a bunch of toxic, gatekeeping chuds say shit like "just change the batteries in your smoke detector bro, it's not that hard." I didn't even understand most of those words, but when I tell them to make some damn sense, they just tell me to go away!
 
So for those who have a knowledge on building a OS from the ground up I'll ask your opinion: Was Terry Davis that much of a genius as his fanbase (and this forum apparently) claim to be?

After talking a look at Temple OS and its features dosen't seem anything impressive and from an user POV there are some stuff that seem rather counterproductive or outdated. But the question that begs to be asked is: What was the purpose of Temple OS objectively speaking?
 
  • Thunk-Provoking
Reactions: UERISIMILITUDO
Writing all of that stuff by himself is no small feat. The purpose is in the name: building one of God's 4 temples (in OS form). Whether you believe that purpose was achieved is up to you.

Also, in his more lucid times he had a lot of genuinely great insights into computer science and the engineering aspect of it all. Very practically minded when he needed to be.
 
After talking a look at Temple OS and its features dosen't seem anything impressive and from an user POV there are some stuff that seem rather counterproductive or outdated.
Thing is, if you compare TOS to, say, Windows or Linux, well, of course it doesn't compare. It's when you compare TOS to other one-man projects that it becomes more impressive. I'm not sure there's a bigger one-man project.
 
So for those who have a knowledge on building a OS from the ground up I'll ask your opinion: Was Terry Davis that much of a genius as his fanbase (and this forum apparently) claim to be?
Terry was definitely competent and could have had a solid career if he hadn't been insane, but the genius claim imo mostly goes back to memes and the mysticism around OSes and languages. TempleOS isn't really amazing on a technical level; it's an unusual type of hobby OS (most try to be a Unix rather than a C64) with an usually long solo dev time of 12 years and even more unusual circumstances surrounding the dev.
 
Back