71–80 of 113 posts
Earlier quoted context omitted.
Unity's multi-platform track record is quite solid at this point in time. I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…
I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…
There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…
Was the reply we got in the old days, when one used C, Pascal, Basic, Amos.
Thankfully many ignored that and moved the state of art to such languages.
A few years later the reply would be,
1. Refused to use C
When devs tried to use C++ or Delphi.
State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
Earlier quoted context omitted.
Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
there's actually a pretty serious niche of us Go game developers growing as well
Earlier quoted context omitted.
>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line o…
Except for some of us, it isn't actually that fun to spend 5 minutes gluing together 6 libraries with no documentation, and 4 hours figuring out an undocumented bug deep in the source code. We would rather write someone from scratch :) Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.
For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo.
Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair."
Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
This blogpost gives the other point of view: http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f... Essentially that the engine you use can constrain what you create, so write your own.
Earlier quoted context omitted.
I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to s…
Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.
Earlier quoted context omitted.
>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line o…
I've got that same feeling when I started using zapier. The amount of tasks you can automate without modifying nor writing any code is incredible. Since last year, I added webhooks to every action in every system I make, and then I use both zapier and huginn to send analytics, add users to mail groups, notify me when something goes wrong, and even make systems that write everything to Google sheets.
There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes fo…
1. Refusing to just use Assembly. Was the reply we got in the old days, when one used C, Pascal, Basic, Amos. Thankfully many ignored that and moved the state of art to such languages. A few years later the reply would be, 1. Refused to use C When devs tried to use C++ or Delphi. State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.
There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.