Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


Game development with Java


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
25 replies to this topic

#1 Eamonn Rea   Members   -  Reputation: 54

Like
0Likes
Like

Posted 29 July 2013 - 08:56 AM

So, I am 13. Yes, I've been told there are serious legal issues because of this. Let's put them aside for a moment, and focus on the main question.

 

I've been coding in Java recently, and I love it. It's my favourite language(next to Lua)! So, I found LibGDX. Yes, it didn't really make sense, but now it makes a whole ton of sense! But, even though I love it, is it suitable to make a good game? Minecraft was made in Java, and it's kind of slow. Yes, it is badly coded and that is a big problem too, but anyway. The biggest game I'd ever wanna make with LibGDX is a Minecraft clone. If I make that, that'll be like the climax of game development for me(though I will still continue).

 

People have said Java is slow. Some argue it is wrong, because it has gotten better now. Yes, some parts of the language is slow, but not as slow as it was.

 

People say that Java can be as fast as C++, depending on how efficient your code is. Maybe even just a little slower.

 

So, should I continue to use Java for game development, or is it pointless(keep in mind about the best game I'd wanna make)?

 

Thanks! Any help is appreciated!



Sponsor:

#2 SyncViews   Members   -  Reputation: 465

Like
2Likes
Like

Posted 29 July 2013 - 09:34 AM

Well Minecraft's performance issues seem to be more than just a language choice. It is also likely over 100,000 or so lines of code (I have 13,000 just to efficently generate and render some voxels), so not likely to be a good solo project target.

 

I did some bits with OpenGL in Java and never encountered any problems I could not solve with some effort. The only things I really missed there was being able to have vectors and oher such objects treated largely like a primitive syntactically, and the need to wrap an interface that is not an object into an object did not seem that great ("GL gl = getGlFromSomewhere(); gl.glFoo()" rather than just "glFoo()" in C/C++).

 

The problems faced by Minecraft would apply to other languages as well. Namely working out how to efficently render a dynamic voxel landscape (rather than a nice pre-created mesh from a 3d modelling program), and how to run logic on multiple threads. So learning an easier language (e.g. Java rather than C) would be a good idea if you plan to take those on within the next few years, I also am not aware of any off the self engines that will solve them for you.

 

 

One thing I will note on my latest project (which is a minecraft type thing with a voxel landscape) however is that using Direct3D (with C++) made for some far nicer debugging expierences than some similar ones with OpenGL. Being able to use the Microsoft tools to step through the rendering of a frame action by action (and going, "that texture coordinate is completely wrong") is really useful. When I first did OpenGL directly I had a lot of annoying things like objects being transformed off the screen, backface culling being wrong, some other code changed a state and did not put it back, etc, and most of them have no errors reported by the API, and also nothing gets drawn to the screen.


Edited by SyncViews, 29 July 2013 - 09:35 AM.


#3 Kaptein   Prime Members   -  Reputation: 2174

Like
2Likes
Like

Posted 29 July 2013 - 09:34 AM

A badly written c++ program is woefully slower than a well written java program

If you ever find yourself wishing that you were writing C++ because of the potential speed gains as a beginner, you're focusing on the wrong things

 

It will take you years, if not decades, to get to the point where you can not only write perfect backends for your games, but also exploit C/C++ to get that extra juice out

Last but not least, for every line in Java you write, you'll need about 50 in C++, in my experience smile.png

But, you know, I have a tendency to write everything myself. Take that last one with a grain of salt. You do learn alot by doing it, though.


Edited by Kaptein, 29 July 2013 - 10:48 AM.


#4 Memories are Better   Prime Members   -  Reputation: 769

Like
4Likes
Like

Posted 29 July 2013 - 09:42 AM


People say that Java can be as fast as C++, depending on how efficient your code is. Maybe even just a little slower.

 

Don't obsess over speed, just follow practices and principles of whatever language and game development in general and you will be fine. I don't know about Java but this speed scare tactic on languages really has to stop and im sure Java has some way to interop with C++ just as C# does.

 

I am not hating on C++ either, I use the language happily with C# and neither compilers complain. Pick the language you like, avoid comparisons (seriously just avoid them or you will go mad) and enjoy.

 

Also what legal issues? :S



#5 Eamonn Rea   Members   -  Reputation: 54

Like
0Likes
Like

Posted 29 July 2013 - 09:56 AM

Legal issues being that a moderator in this forum told me that I need to be 18+ to submit a game to Steam/iOS/Android. I've seen people that are 13-15 year olds write Android apps though, so Google won't ban a 13 year old for submitting an app and going against their Terms(it states in the apps that I have saw that the submitter is 13), but they'll ban an app for having the word "SEO" in their description.

 

Algorithms: Yes or No? I was told to learn them twice, and told not to 5 times. Algorithms are meant to be about getting really REALLY close to the metal, which I don't plan on doing. I know how painful comparisons are. Python VS Lua VS Ruby.... ughh!

 

Yes, Minecraft would not be a good solo project. I just said that a Minecraft-type game would be my big goal, so you'd know whether or not Java is right for me. 



#6 SyncViews   Members   -  Reputation: 465

Like
3Likes
Like

Posted 29 July 2013 - 09:57 AM


Also what legal issues? :S

The only one that comes to mine is it is generally required for one to be at least 18 before they can sign contracts, such as a non-disclosure agreement (NDA), which would make working in a team difficult. I seem to recall that a parent can sign on behalf however, but it still complicates things a bit.

 

EDIT:

I expect that the processes for submitting to app stores such as apple and google include legal agreements. I am also not sure how tax applies.


Edited by SyncViews, 29 July 2013 - 09:59 AM.


#7 Eamonn Rea   Members   -  Reputation: 54

Like
0Likes
Like

Posted 29 July 2013 - 10:03 AM

 


Also what legal issues? :S

The only one that comes to mine is it is generally required for one to be at least 18 before they can sign contracts, such as a non-disclosure agreement (NDA). I seem to recall that a parent can sign on behalf however, but it still complicates things a bit.

 

You hit the nail on the head my friend! :D



#8 David.M   Members   -  Reputation: 731

Like
3Likes
Like

Posted 29 July 2013 - 11:51 AM

If you haven't looked through LibGDX's gallery I would check that out. A few of the more popular games made using LibGDX being Apparatus, Clash of the Olympians, and Ingress.

 

Yes, LibGDX is fine for game development and I enjoy using it. There's a great community behind it as well if you ever get stuck. As far as Minecraft and 3D, I believe the 3D API is still in the works. I'm not sure how fully-featured it is. You'll have to look around a bit. I do know it hasn't yet been put into a 'stable' release so you'll have to run the nightly builds which I've been doing with no trouble.

 

I would advise just jumping in and trying it out, at least for a little while. If you don't like it, try something else. If you only really care about desktop deployment you can look at jMonkeyEngine, LWJGL, or JOGL.


Edited by David.M, 29 July 2013 - 11:52 AM.


#9 Pink Horror   Members   -  Reputation: 1213

Like
2Likes
Like

Posted 29 July 2013 - 12:28 PM


Algorithms: Yes or No? I was told to learn them twice, and told not to 5 times. Algorithms are meant to be about getting really REALLY close to the metal, which I don't plan on doing. I know how painful comparisons are. Python VS Lua VS Ruby.... ughh!

 

That is not what algorithms mean. Algorithms are the mathematical version of programming. It's the opposite of the metal. It's the completely abstract land. So yes, learn algorithms. Languages may come and go, but algorithms will remain.



#10 Paradigm Shifter   Crossbones+   -  Reputation: 5409

Like
4Likes
Like

Posted 29 July 2013 - 12:56 PM

Yeah, algorithms are just recipes for doing operations, they don't even need to be done on a computer.

 

When Gauss was 10 years old or thereabouts, his Father told him to occupy himself for a while by adding up the integers from 1 to 100. The story goes that as he was walking up the stairs he realised that 1 + 100 = 101, 2 + 99 = 101, etc. and there are 50 pairs of numbers between 1 and 100, so the answer was 50 * 101 = 5050. That forms the basis of an algorithm for adding numbers from 1 to N (when N is even, working out what to do isn't hard for odd N though) which is more efficient than summing 1 + 2 + ... + N. Algorithms exploit things like that to do operations in a more efficient way (in general, anyway).

 

EDIT: Embarrassing addition fail typo ;)


Edited by Paradigm Shifter, 29 July 2013 - 12:57 PM.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#11 TheChubu   Crossbones+   -  Reputation: 4573

Like
0Likes
Like

Posted 30 July 2013 - 01:59 AM

Let me see if I remember the definition:

 

A finite amount of steps that in a sequence are meant to resolve a problem.

 

Wikipedia's def:

An algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function.
Ahh, close enough :P

 

 

Well Minecraft's performance issues seem to be more than just a language choice. It is also likely over 100,000 or so lines of code

150k from what I've seen. For comparison, IdTech 3 engine is 160k lines of code IIRC, and that's the barebones engine, Minecraft has all the gameplay code and barely loads any external data as far as I remember (maps + textures and thats it, I think even mob meshes are defined in code).

 

And another reference, this guy has been coding a voxel MMO for the past 2-3 years, its nowhere near finished, and he was an IBM engineer :D Though he heavily invests on multi platform support with almost no additional libraries (which means that he codes most of what he needs instead of using 3rd party libs, multiple render back ends, etc, and this is C++ mind you).


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#12 Malabyte   Members   -  Reputation: 589

Like
0Likes
Like

Posted 30 July 2013 - 09:00 AM

Afaik the reason why Minecraft runs slowly at times and the chunks update very poorly is most likely because of how the voxels are rendered, as well as the fact that:

1) - Each world chunk is currently 16x16x256 blocks in size.

2) - Far render distance equals 10 chunks in all directions, which essentially equates to 21x21x16x16x256 = 28+ Million individual voxels reloaded every single game tick.

 

The optimization of voxels in a game world mainly (afaik) deals with how the voxels are shown, which sides are rendered when, and so forth. Voxels that lie in-between other voxels are simply not rendered on any sides (until you dig down to them). I have no idea how it works in Minecraft, but I do know that simple lines in the code can result in tremendous improvements to performance. And it's definitely an algorithmic and problem-solving issue that has little to do with the programming language that you're using (at least at default, as there might be some exceptions for all I know). It seems to me like the chunks in Minecraft that sometimes disappear and can't be seen until you literally stand on top of them, is some form of failsafe so that the game won't crash whenever there's too much going on in the code. But I'm not sure.


Edited by Malabyte, 30 July 2013 - 09:03 AM.

- Awl you're base are belong me! -

- I don't know, I'm just a noob -


#13 nczempin   Members   -  Reputation: 108

Like
0Likes
Like

Posted 04 August 2013 - 04:58 AM

Yeah, algorithms are just recipes for doing operations, they don't even need to be done on a computer.

 

When Gauss was 10 years old or thereabouts, his Father told him to occupy himself for a while by adding up the integers from 1 to 100. The story goes that as he was walking up the stairs he realised that 1 + 100 = 101, 2 + 99 = 101, etc. and there are 50 pairs of numbers between 1 and 100, so the answer was 50 * 101 = 5050. That forms the basis of an algorithm for adding numbers from 1 to N (when N is even, working out what to do isn't hard for odd N though) which is more efficient than summing 1 + 2 + ... + N. Algorithms exploit things like that to do operations in a more efficient way (in general, anyway).

 

EDIT: Embarrassing addition fail typo ;)

Not his father, his school teacher, "Büttner".



#14 Davai   Members   -  Reputation: 105

Like
0Likes
Like

Posted 06 August 2013 - 01:07 AM

 


People say that Java can be as fast as C++, depending on how efficient your code is. Maybe even just a little slower.

 

Don't obsess over speed, just follow practices and principles of whatever language and game development in general and you will be fine. I don't know about Java but this speed scare tactic on languages really has to stop and im sure Java has some way to interop with C++ just as C# does.

 

I am not hating on C++ either, I use the language happily with C# and neither compilers complain. Pick the language you like, avoid comparisons (seriously just avoid them or you will go mad) and enjoy.

 

Also what legal issues? :S

 

The idea that Java is inherently slow is twofold.  Firstly, the early java runtimes Were (prohibitively) slow in handling certain things.
Secondly, it is Interpreted.  I would like to assume veryone here knows what this means but the new generation of programmers is woefully lacking in fundamentals..so -

Imagine you wanted to add two 8bit integer values together (among the fastest processes an x86 series processor can perform if the AX register is used.)

Under Java, no matter how efficient the source code, there will be a quantity of processing cycles devoted to Reading that source (or bytecode in so-called "compiled" java), more to process tables to determine the correct native process, and then sending them down.

Under a compiled language, C++ for example, all of that overhead is done in advance.  Source code is read and processed and boiled down into the list of machine instructions as an Exe-cutable, Com-mand, etc.


To be honest tho, if your target game is so processor-intensive to require a lower level language, then simply having enough knowledge to put the thing together likely also means you know enough to make that decision in advance.
 



#15 SimonForsman   Crossbones+   -  Reputation: 6175

Like
1Likes
Like

Posted 06 August 2013 - 02:03 AM

 

 


People say that Java can be as fast as C++, depending on how efficient your code is. Maybe even just a little slower.

 

Don't obsess over speed, just follow practices and principles of whatever language and game development in general and you will be fine. I don't know about Java but this speed scare tactic on languages really has to stop and im sure Java has some way to interop with C++ just as C# does.

 

I am not hating on C++ either, I use the language happily with C# and neither compilers complain. Pick the language you like, avoid comparisons (seriously just avoid them or you will go mad) and enjoy.

 

Also what legal issues? :S

 

The idea that Java is inherently slow is twofold.  Firstly, the early java runtimes Were (prohibitively) slow in handling certain things.
Secondly, it is Interpreted.  I would like to assume veryone here knows what this means but the new generation of programmers is woefully lacking in fundamentals..so -

Imagine you wanted to add two 8bit integer values together (among the fastest processes an x86 series processor can perform if the AX register is used.)

Under Java, no matter how efficient the source code, there will be a quantity of processing cycles devoted to Reading that source (or bytecode in so-called "compiled" java), more to process tables to determine the correct native process, and then sending them down.

Under a compiled language, C++ for example, all of that overhead is done in advance.  Source code is read and processed and boiled down into the list of machine instructions as an Exe-cutable, Com-mand, etc.


To be honest tho, if your target game is so processor-intensive to require a lower level language, then simply having enough knowledge to put the thing together likely also means you know enough to make that decision in advance.
 

 

 

Actually Java is JIT compiled these days(and has been for a very long time), so the bytecode (or frequently executed parts of it) get converted to native code at runtime (either before it starts or while it is running), apart from a short warmup period at the start of a programs execution or a delay while the program loads(depending on JVM version and settings) Java applications will perform at native speeds on most architectures (This also allows some JVMs to do some nice optimizations for things like dynamic dispatch(inlining the most common version and replacing it if the usage changes for example) that ahead of time compilers simply cannot do which allows it to greatly outperform c++ compilers such as g++ and msvc in some very artificial benchmarks)

 

Also, there is nothing in the Java language that prevents it from being compiled in advance, compilers such as gcj do just that (allthough it doesn't support the latest version of the language and the machine code it produces ahead of time actually performs worse than the JIT compiled machinecode Oracles JVMs produces these days so interest in improving ahead of time compilers for java is pretty much gone. (Most resources these days go towards improving JIT compilers).

 

The performance issues you get with Java today has almost nothing to do with it being JIT compiled(Allthough time consuming optimizations are hard to pull off with a JIT compiler without annoying the user) but rather with the lack of low level control, excessive security checks, high cross architecture accuracy guarantees on operations and lack of manual SIMD instructions, C# is a bit better in that area (mono has SIMD support (allthough its a bit clumsy) and you can use unsafe code to avoid security checks you don't want to pay for)


Edited by SimonForsman, 06 August 2013 - 02:05 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#16 SyncViews   Members   -  Reputation: 465

Like
0Likes
Like

Posted 06 August 2013 - 02:21 AM

GCC/ICC and MSVC all have profile guided optimisation if you put some effort in (slightly harder for games. With some business components I wrote it is simply part of the build script for releases). I usually see about 10 to 20% on my stuff for those builds, it is just automatic with Java since it can do it at runtime.

 

But Java/C++ should in theory be still very close. The one bit I never really had time to look into is why in practice they are often not very close. E.g. at university I needed to do some image processing / AI stuff. In Java when running the app to see if the results were what I wanted was taking really long (since it had to "train" on a few hundred samples at least, then process the real samples to see if they were correctly classified). I did not have much time to investigate, but I copied one filter that seemed to be really slow into C++ with minimal changes, and timed how long it took to run that filter on a set of preloaded images. The C++ was 5 times faster, even though the code was basically the same. MSVC2010, 32bit build, so would not have even been getting free SSE gains (infact even with x64 I do not believe 2010 ever vectorises a lot of things) while Java in theory could (64bit Win7 on a Core 2 Duo).

 

Of course if I had time the image filters most likely should have been rewritten to use the GPU anyway.



#17 SimonForsman   Crossbones+   -  Reputation: 6175

Like
1Likes
Like

Posted 06 August 2013 - 02:45 AM

GCC/ICC and MSVC all have profile guided optimisation if you put some effort in (slightly harder for games. With some business components I wrote it is simply part of the build script for releases). I usually see about 10 to 20% on my stuff for those builds, it is just automatic with Java since it can do it at runtime.

 

But Java/C++ should in theory be still very close. The one bit I never really had time to look into is why in practice they are often not very close. E.g. at university I needed to do some image processing / AI stuff. In Java when running the app to see if the results were what I wanted was taking really long (since it had to "train" on a few hundred samples at least, then process the real samples to see if they were correctly classified). I did not have much time to investigate, but I copied one filter that seemed to be really slow into C++ with minimal changes, and timed how long it took to run that filter on a set of preloaded images. The C++ was 5 times faster, even though the code was basically the same. MSVC2010, 32bit build, so would not have even been getting free SSE gains (infact even with x64 I do not believe 2010 ever vectorises a lot of things) while Java in theory could (64bit Win7 on a Core 2 Duo).

 

Of course if I had time the image filters most likely should have been rewritten to use the GPU anyway.

 

Most likely you used arrays or created temporary objects, java does bounds checking on all array accesses(for image processing it is quite natural to use arrays and you will access them alot), C++ does not (unless you explicitly add bounds checking or use vectors (allthough boundschecking on c++ vectors should be disabled in optimized release builds) and it adds up, newer versions of the JVM can eliminate some boundschecks though but you have to write the code in a way that makes it obvious that the bounds check can be safely ignored.

 

There is also an issue with trigonometric functions(which may be used in image processing) with Java on the x86 platform. (the x86 trig functions are too inaccurate for the Java specification if you use big arguments so it will perform a manual argument reduction (which can add quite a few instructions to each trig function on x86, your best bet there is to do a lower precision argument reduction yourself to keep the arguments in the accurate range)


I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#18 SyncViews   Members   -  Reputation: 465

Like
0Likes
Like

Posted 06 August 2013 - 02:58 AM

Well the only temporary objects were the same ones I used new/delete on in C/C++, so no issue there. Although I kind of hope Java can optimise out small temporaries like 2d and 3d vectors (since for many tasks using multiple primitives instead is a bit of a pain and duplicates code).

 

Most of the filters were in the form "BitmapG myFilter(BitmapG in)", where BitmapG (or in other cases things like BitmapRGB) was just a a new bitmap the same size as the input. There was then some loop such that "x >= 0 && x < in.GetWidth()" and "y >= 0 && y < in.GetHeight()", with pixel access being "data[y * width + x".

 

I would really hope Java can deal with that, in C++ I had enough trouble getting things like World::getBlock(x,y,z) to run at a reasonable speed and not be the main hotspot, Id hate to be trying to do that in Java/Minecraft if every array access it does bounds checks (getBlock requires 2 + a small array based hash table, and Minecraft has metadata as well which I don't, which I am sure is a separate array). Would effect most other practical CPU limited processing I can think of as well.



#19 SimonForsman   Crossbones+   -  Reputation: 6175

Like
1Likes
Like

Posted 06 August 2013 - 03:21 AM



Well the only temporary objects were the same ones I used new/delete on in C/C++, so no issue there. Although I kind of hope Java can optimise out small temporaries like 2d and 3d vectors (since for many tasks using multiple primitives instead is a bit of a pain and duplicates code).

 

Most of the filters were in the form "BitmapG myFilter(BitmapG in)", where BitmapG (or in other cases things like BitmapRGB) was just a a new bitmap the same size as the input. There was then some loop such that "x >= 0 && x < in.GetWidth()" and "y >= 0 && y < in.GetHeight()", with pixel access being "data[y * width + x".

 

I would really hope Java can deal with that, in C++ I had enough trouble getting things like World::getBlock(x,y,z) to run at a reasonable speed and not be the main hotspot, Id hate to be trying to do that in Java/Minecraft if every array access it does bounds checks (getBlock requires 2 + a small array based hash table, and Minecraft has metadata as well which I don't, which I am sure is a separate array). Would effect most other practical CPU limited processing I can think of as well.

 

Actually quite a few classes in Java are immutable(String is a common pitfall, allthough not one relevant to image filtering) and will create temporary objects for you if you try to modify them.

 

The arithmetic you do on the index (y*width+x) is most likely enough to prevent the client VM from eliminating the bounds check since there is no obvious link between the length of the data array and in.getHeight() and in.getWidth() at compiletime, with Java it is usually better to loop over a single index (for int i=0; i<data.length(); i++) { do stuff with data[i] here, it is obvious that data[i] will be in bounds as long as i doesn't change inside the loop so the bounds check should be trivially eliminated, you can calculate x and y from i as long as you know the width if you need them for the filter function }

 

But yes, writing code that manipulates large blocks of data quickly in Java is a pain in the ass, knowing the language and its quirks helps quite a bit though.


Edited by SimonForsman, 06 August 2013 - 03:24 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#20 SyncViews   Members   -  Reputation: 465

Like
0Likes
Like

Posted 06 August 2013 - 03:31 AM

So would a 2D array likely have been better, even though for say [y][x] (as well as the order being somewhat confusing) creates height+1 separate arrays (and then likely requires a temp and memcpy if it ever interacts with native code, e.g. to display it)? In 3D for a block game like minecraft that seems even worse.

 

If not then I guess that is actually a good reason to suggest building stuff like Minecraft in C.


Edited by SyncViews, 06 August 2013 - 03:31 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS