Is there anything wrong with java for making games in 2018?

Is there anything wrong with java for making games in 2018?

We literally have supercomputers now.

Your choice of programming language doesn't matter, because it's not like anybody's going to play the games that you will make.

you know, that kind of statement says more about you than OP
I hope you'll feel better soon (and less bitter)

Good morning, Pajeet.

>>almost 2018
>>not using C# for gaymes development
>>not M$ master race

I dont know user. Are you even trying?

Doesn't matter as long as you actually make it. People shit on Notch for how Minecraft was written but he's worth more than all of those fags put together.

No I've written more than him fucking faggot kill yourself

How bout you pay me to do i-
Oh, sorry.

No but know java really shine when you give the jvm lot of memory and as far as i know you don't have access to the hardware of your users to upgrade it when needed.
If you can work around that it's a decent choice but not the best.

I mean it's Turing complete, so you COULD make games on a massive series of flipping stone on the beach, but that doesn't mean it's smart

Depends, is this a graphically or computationally heavy game? It might matter. If it's something simple then it's fine. People who complain your game is 5mb vs 5kb don't really care about playing games anyway. Worry more about using tools you know to make what you want to happen happen.

No, most gamedevs are just retarded dropouts who can't into high-preformance computing so they perpetuate memes about GC'd languages.
Take as an example a branch of fintech where you need to
>accept packet
>process said packet (nontrivial, computationally heavy)
>send packet
in under 10ms if you don't want to be losing millions per day. Most prevalent language is Java, with custom ASICs for networking being common. The processing is all done on JVM and it's far more expensive than anything any game does in a frame (you're analyzing the information in context of gigabytes of data at the very least). Yet gamedevs struggle to do their laughable workload in 16.6ms without using C++, pathetic. A trader running on shitty 2010 xenon is competitive enough, why can't gamedevs do anything right?

>why can't gamedevs do anything right?
Fuckall control over hardware and doing 100% of the work with 50% of the time?

JNI gets messy in a hurry.
If you don't need OpenGL, and all of your rendering will be on the CPU, then it won't be an issue.

Hardware control isn't the problem, you can determine all relevant variables at runtime- $ size, bandwidth, w/e a retarded gamedev needs. The difference between AMD and Intel chips, is not so significant as to make the difference between hitting 16.6ms and not.
We're shipping traders within 1 year and they are competitive, while having much higher performance requirements (and code quality too- you don't want to lose $500k in one bad transaction because you write shitty software). I sincerely doubt the result of 2 years+ of work is so ridiculously bad, most time-consuming part is certainly assets (if not, your programmers are shit and you should fire them). There's no excuse in anno domini 2017 for not hitting 16.6ms with the kind of workset AAA games have.

>Hardware control isn't the problem, you can determine all relevant variables at runtime- $ size, bandwidth, w/e a retarded gamedev needs.
No you can't because you keep hitting edge case after edge case, go take a look at the graphic part of engines it's fucking retarded and it get even worse if you consider doing multiplaftorm. We're still getting fucked by opengl 2.1 a decade later, ati/amd's driver are complete shit, laptops are landmines, isp throttle, drop packets randomly and provide shit routing to their customers.
You spend all your time playing whack a mole because all this bullshit is out of your control and there's nothing you can do but fix it AFTER it happen.

>brainlet gamedev is so retarded he can't come up with a protocol that doesn't kill him when the network suddenly changes topology
>brainlet gamedev is so retarded he can't into optimizing for gpu that he has to resort to vendor-specific hacks that break OGL spec
You can query the gpu for all features it supports, you can run benchmark to generate performance profile that's relevant to your rendering pipeline. If you decide you want your game to support some mysterious "PC" machine, it's only your fault for getting bitten by it. If you abstract hardware to such a degree that it no longer has anything you can rely on, it's your fault. You should abstract hardware so that you can still rely on specs. Getting around drivers isn't gamedev's job, you bitch about it at nvidia or amd, it's on them to fix and it's on you to test if your game works before shipping it.

Notch used Java to create Minecraft because that's was the language he was more comfortable with. Now he's a billionaire.

LWJGL has all the JNI work done for you for OpenGL, GLFW, OpenAL, and more. Even has Vulkan bindings. Anyway there's higher level libraries like jMonkeyEngine and libGDX available.

>i have no experience in this field but i can tell you how it work
Nah mate it doesn't work like that but you can pretend all you want, if you knew what you were talking about you'd know specs are broken all the time and not always fixed in a timely manner so what do you do? Leave the bug to rot and upset your customers or slap a 10 lines fix and call it a day?

the "java is slow" meme needs to go away. sure, it might be slower than c/c++ (and even then, not always), but it literally won't matter if you're not writing some super heavy software. as long as you're hitting 60 fps, you're fine.

and it sure as fuck is faster than anything interpreted/JIT'd out there.

Java can be fast, it's just that most game devs are too lazy/dumb to optimise
Minecraft is a perfect example

>beta gamedev can't get vendor to fix a bug that breaks fucking spec
I can't even. I work with shithead vendors that decide to break specs for no reason at all. You just generate so much shit that they have to deal with it (usually within 2 days if it's not hw). You want to tell me gamedevs don't have influence over GPU vendors when it's their biggest source of income? Fuck off. If you're indie, you're certainly not making a game that gets even close to HW limits and AAA publishers certainly do have the influence.
No matter how ridiculously bad the spec is (OpenGL is shitshow), it is a spec and you can rely on it, unlike vendor-specific hacks that can (and will) break anytime. Don't cry your environment is bad, go make it better by pressuring the vendors to fix their shit. There is no excuse for games to be this bad with the amount of work put into them.
Moreover if gamedevs didn't suck at optimization, they wouldn't need to dive into the nitty-gritty of gpu drivers just to fuck it all up. But i get it, the ridiculously low salary doesn't attract anyone but the most desperate monkeys. Afterall it's the sort of people that can't make a multiplayer game that wouldn't break with latency spikes. Gamedevs are the laughing stock of the whole industry, even pajeets laugh at them.

You can make a game with java just as you can with C++ or even python, javascript, etc... Real factors that would influence my decision on a language would be where I wish to deploy my game, my current skill set, do I wanna make the engine myself or use something like unreal or unity, and anything else you can think of.
If you're limited to just java then use that. It'll be a good learning experience if anything

Why do you think you get bugfixes if not thanks to gamedevs pressuring them? You reap the reward and then complain nothing happened, literally a soccer mom.

We don't use GPUs in work, i was talking about sigenics, cisco, ibm and other vendors that are much worse when it comes to breakings specs (mostly sw vendors or various brokers and their shitty APIs). I don't do games in my free time, i have one project where i use OpenCL heavily and guess what, if you stick to the spec, it works (on linux, no idea about win). I sincerely doubt gamedevs have any influence on vendors not breaking OpenCL, so kindly fuck off.
What i know though is we had this guy from insomniac on trial period in our shop, well he didn't last because he was a moron who thought optimization is "let's use divide&conquer algos for everything, it's cache-oblivious no?", fucking retard. He's not why i generalize gamedevs to be retards though, it's from attending SIGGRAPH and other conferences where i spent 80% of the presentations facepalming.

>work on my machine
How could i be so blind when the solution was right before me?

It works on all the hardware i've owned throughout 6 years, and that covers more than 10 pieces of hw from both vendors. I test if it still works on the old hw from time to time and have never had a problem. Maybe you're just too retarded to follow specs and blame it on vendors.
Our traders have to work on pretty big variety of hardware and they also work, all the prats of them- be it Java, Haskell or C++, all the components work, all the time (because if they didn't we'd be out of business already). Are gamedevs too retarded to do quality control? Or is it because they think they're the next incarnation of Ritchie? Follow the spec, don't do shitty hacks just to ship a day earlier and you'll be good, how hard is it to understand?

>Follow the spec, don't do shitty hacks just to ship a day earlier and you'll be good, how hard is it to understand?
But you told me even a big boy like you have trouble following the spec because vendors break it all the time. I'm getting mixed messages here please enlighten this simple brainlet my liege.

No i told you a big boy like me always follows the spec and, when vendor decides to break it for no reason, i get all the relevant people involved, we do a shitstorm at the vendor and the vendor fixes it because he's not willing to lose 20% of his business for his retardation.
Always. Follow. Specs. It's that simple.

Notch here, can you get my lambo from the Shop?

this guy is a fucking wageslave retard

Ha yes i see now, but what about your clients? After all until proved otherwise the fault is on you since you didn't test your software thoroughly.

Better being wageslave and retire in 40 than being a neet who'll be homeless after his parents die.
>he doesn't even check if his sw is working before delivering it
W-we really tested our game b-before release, i s-swear - Bethesda.
In 8 years here, we didn't have single complaint from our customers. Well we did, but it was mostly UX shit that i'm not responsible for, it was apparently too customizable for the average guy and they wanted some sensible defaults, so we did that.
You see our customers aren't retarded neets, kids and man-children so they care a lot about quality of the software they pay for. It might go well for game publishers if they release pre-alpha shitshow for 50$ and market it as complete game (bonus points for built-in gambling, DLCs for another 100$ at least, [X] edition, pre-orders and all that ridiculous shit you are willing to swallow), but it would kill us if we did anything close to that. It would kill most companies that ship software to non-retarded customers though.

>learn java, python and C#
>do a small MVC game demo
>don't be a complete social retard
>get job as indie dev

it literally is that simple, user. Maybe learn swift along the way to port it to ios.

IMO you should strive to make your software efficient, even in the age of much better hardware.

Efficiency doesn't mean writing it in low-level shit language if you can afford to write it in high-level shit language (which you can, even in the case of AAA games). Do you write your software in machine code?

I am not a programmer (yet), unfortunately. I just have some strong opinions and big dreams. I also wasn't necessarily talking about low level versus high level languages, but rather caring enough to do things like making your own engine instead of using something like unity, that way you can make things more efficient.

>everything is cubes
>still runs like trash

Anyway, you like oranges but why compare them to apples?

There's nothing wrong with java. Stop bandwagoning and use what you want where you want to. If you like java and game development, go ahead.

I work on a performance team at a major tech company and we use Java for a lot of things you wouldn't think it should be used for

All software should be held to the same standard of quality. Unfortunately, this would bring progress to a halt most likely, since vast majority of programmers couldn't achieve such standard (considering they struggle with basic verification). A HFT is close enough to a game to hold it to the same standard of quality though- both must run on variety of hardware, both have specified performance target, both have hard deadlines, both are (usually) bottlenecked by bandwidth, both have to make clever use of computational resources, both have to deal with vendors breaking spec. Why is it that games are never working on release, while traders are never broken on release? Customers that buy games are faggots that gladly take publisher's cock deep into their anuses, while customers that buy traders are jews that really, really don't like their shekels disappearing into thin air because a retarded developer didn't do his job.
Gamedevs are simply incompetent, it might not be their fault, but that's just how it is- they can't bring a working product to market.
You greatly underestimate how many man-months a commercial engine saves you. If your goal is to make a (nontrivial) game, don't start from scratch. Moreover, even if you did create your own engine specifically architected to the needs of your game, chances are you'll end up with worse-performing product than if you used commercial engine, unless you have at least some experience.

We've been at it for 3 hours now and i'm running out of baits so lets put shitposting aside for a minute since i'm curious about your job now.
I know exactly jackshit about HFT but after a quick check it doesn't look like anything you have to do in game development except for the networking part, and even then the goals are different. Games try to keep client in syncs while dealing with varying amount of lag and packet loss without impairing the gameplay(ideally) while HFT is focused on sending packets as fast as possible with the best existing route and to hell with everything else.
Of course that's just me looking on google for about 5 minutes, can you go more in detail?

>Still made millions upon millions
Yeah I'm sure he's super worried about 12 year olds frame rate

Networking isn't the only thing HFT has in common with games. After recieving the packet, we have to process it in some context (usually gigabytes of data), this is nontrivial and it's actually what i've been working on for most of my career. This step is pretty big in contemporary HFT systems, as complex strategies will get you much higher profits than just being the fastest to complete transaction.
Some parts of this step are quite similar to games. We parse the data into appropriate data structures, like renderer sorts its data into render groups or whatever abstraction you chose to work with, we do heavy processing on these data structures, again just like renderer does in the pipeline. Depending on the client, the strategies can be as simple as basic linear algebra and analysis, or as advanced as non-stable K-theory (this was probably the most advanced area of math i had to study to finish a product). The window for this step is usually around 3ms because receiving and sending the packet is what takes the most time. The computations are usually paralellizable, but complex strategies have lots of sequential steps. In sequential strategies, we sometimes step down to C++ (or Fortran, even asm) to hit performance target, but most of our traders are Java and Haskell, with network being done on ASICs. The times when all you wanted from trader was to be the fastest to make transaction are long gone.
This is all coordinated by a lower-sensitivity system that does stock prediction, but the short-term goals are all governed by the trader in the processing stage because of latency.

Java newbie here, can someone learn this power? To write efficient Java?

It's nothing extraordinary, JVM is extremely good you just have to know how to play to its strength, this means you need to know how JVM works. But that's the case for every language you pick- if you want to write efficient code, you have to know your platform. In case of Java, this is JVM, in case of C++, this is whatever set of hardware you're targeting, in case of Haskell, this is GHC. If you don't know how your platform works, you're not going to write efficient code.

Any books on the JVM to look out for? I've only ever come across Java focused textbooks that mostly just say the JVM handles garbage collection and you can't do much about how or when or where.

You can make a game in any language, and it would most likely run okay on any modern computer, assuming you didn't need Crysis levels of computation to begin with. Java can indeed be used for making decent games. It was used to make Minecraft, was it not? But if you've played Minecraft enough, you would note that there are times when the game can get slow, particularly when it has to handle larger redstone contraptions and certain world types (e.g. the sort of "even more extreme hills" variants). In these such cases, while it might be the case that better hardware could lead to handling the situation better, it begs the question, "what if Notch actually cared about performance?" If Minecraft were written in C++ from the start, could we handle even more?

Not same user, but of course - it just takes a lot of time & reading and its also comp.sci algorithm theory and maths (often more so than langauage specifics) that matter.

Javas ecosystem gives you a lot of help if you can buy licenses for software or make use of open sauce licensed stuff too. Java has a lot of good libs for a lot of situations.

Don't allocate gobtons of memory all the time and try to make use of arrays of plain old data types more. Idiomatic Java lends itself to lots of cache misses. Also, Java is really good at optimizing tight loops. Play that to your advantage.

Minecraft was slow because Notch used fixed pipeline OpenGL. Didn't have anything to do with Java.

> If Minecraft were written in C++ from the start, could we handle even more?
Probably not if the code was as shit as Minecraft's.

But the modders would have had A LOT more problems hooking their code into it than with the JVM, I'm pretty sure of that.

I don't think books are good resource to learn JVM. The JVM specification is freely available on the internet and it will tell you much more about JVM than any book could. Of course they are good supplementary material to the spec. I don't like recommending books i didn't read, so the only book i'll mention is Java Performance.
>If Minecraft were written in C++ from the start, could we handle even more?
Very likely the contrary. Notch is notoriously bad programmer (not only) when it comes to performance. Bad C++ will most likely be worse than bad Java because JVM does very good job of optimizing shit code, unlike C++ where the compiler doesn't have such freedom.

That's pretty rad i had no ideas so much processing was involved in HFT now i see why you compared that to games and in a sense it's kinda true for example with loading times, you've got ton of processing to do but the given hardware can greatly limit you or in the case of consoles hugely help you because said hardware always stay the same and you can take all kind of shortcuts to go faster.

There was *a lot* more than just that problem. I'm pretty sure even the data structure for the blocks and chunks was fucked up. It's silly how these acted even offline never mind on a server.

Notch is the kind of programmer that I would expect a to make a visual novel game lag and crash. (There aren't actually too few of these programmers...)

How can you fuck up the data structure for chunks? Isn't it just an array of blocks?

And even with all the bandwidth and processing power, along with possibilities enabled by the console hardware, they still struggle to hit 16.6ms on anything reasonably looking. It's really sad, seeing them struggle with that while we're doing much more complex transforms in much less time. In our timeframes, even FFI call is expensive operation and we do some shady stuff with JVM to alleviate some of the cost. Despite this, our shit always works.
One word: OOP
Not really OOP itself, but the OOP as taught in the 90s to early 2000s. It is absolute cache-murderer and cache-coherency matters quite a bit when you're working in the tens-of-ms timescales. Another thing is it forces you to do useless transformations of data.

So no OOP ever if you want efficient Java?

OOP isn't bad per se, but the kind of OOP that C++ and Java pushes you into is bad once you go down to the timescales games work with. Don't be just an anti-OOP zealot, know your shit and you'll see for yourself what is good and what is bad for performance. I'm just telling you that the code you write when you want performance from JVM is quite different from the code on github or in books.
Enough of this though, it's 2:45AM here in yuropoor and i'm going to sleep. Read JVM spec, your Java code will get significantly better.

I wish FloatBuffers weren't cancer

Thanks dude, this has been really enlightening

do it bro

True and there's a few reasons why this is such a mess first being time, there's never enough time to do what you need but that's not exclusive to game development no, what come next amplify this problem.

See in most mid to huge size studios teams and constantly shuffled peoples come and go but mostly go meaning you start with 100 peoples, get your estimation and it's all great, then management cut 60 peoples to send them work on other projects because it's more efficient, and they're right, but now you are understaffed and things have to be cut from development or half assed if you want to get out the game in time.

Next is the project killer we call playtesting, you had an idea and brought it to the world, spent 3 months with the team churning prototypes and concepts and found what appear to be the right thing to create so you get to work to have your alpha ready, it's full of wip textures, some models are just boxes and the gameplay isn't polished but you're proud of your work and send it to playtest, turn out it's not that great and you're back to square 1, hopefully you can salvage some of the work. The money and time invested will never come back.

I bet you love being paid well yeah? Not in gamedev the pay is shit but how can they find employees? Interns, peoples fresh out of school and young and generally peoples who want to be game developers. It's a literal pump and dump technique, except they go away without having to fire them! Amazing! Peoples who leave tend to either try to go indie or change field because it was just awful.

So, you have inexperienced developers working on a new codebase with few veterans to teach them the ropes, a shit pay or nothing at all, crunch time all the time because management sent half your team somewhere else and won't give you more. This right here is your recipe for failure or half finished games with a $70+dlc price tag.
And then you have indie devs, it's different beast.

> 2017 + 1
> Not using pic related for gamedev

I went into Java because I didn't plan on being a gamedev, but now that I'm comfortable with the language and have free time I'd like to see what I can do. What's a good place to start and not make bad mistakes with design or libraries?

JOGL

this isn't 2004

Java is quite a mess of compatibility with audio, joysticks etc etc.. also the garbage collection may make your game hitch like a bitch.
If you really feel like being a lazy fuck, use freebasic with SDL/Open GL.

It supports modern OpenGL. Nothing 04 about that.