Game Engine

Java game engine = slow by the way

Game engine modules usually are:

File I/O (saving,loading)
hard I/O (keyboard/mouse input)
Event handling
AI
Graphics (drawing it)
Resource management (loading the data e.g levels, graphics files, music)

The actual plot etc... is not a part of the engine. e.g one game engine (for example, the unreal engine) powers about 50 different games.

Dont use java though. 99% of game engines are C++ (and maybe a little assembley for the graphics)

Java isn't necessarilly slow. That idea of yours is outdated by 5 years at least. For many applications Java is now as fast as C++ if not faster.

I'll agree, from experience, for most individual tasks, there's not much speed difference between C++ and Java. However; the rigid paradigm inflicted by Java sometimes restricts certain approaches to problems, approaches which, in some cases, could be faster ( or more memory efficient ) than those afforded by sandboxed pure OO... That still stands today.

I disagree. Even after all these years, Java still has to go a long way when compared to C++, at least in terms of Game Development. The kind of raw power achieved by C / C++ _can't_ be offered by Java.

Compare and contrast the implementation of different languages in C and Java and you would know what I am talking about (Rhino v/s SpiderMonkey). Although this _slow_ term isn't really justified in normal application development, it stands out when developing games. Plus the inclination of the industry to still use C as the core language to develop the game / graphics engine, regardless of what they use for scripting is enough proof in itself.

But I don't question the theory that the future holds a lot for newer langauges like Java, Ruby, Python but that time is yet to come.

Python is actually used a bit for the AI in turn basd strategy games such as the Civilization series

Python is used in a lot many games. Severance - 'The Blade of Darkness', 'Freedom Force' and so on. The scripting language Lua has been used in both the original and the expansion of 'Painkiller'. Search up those and you will see these really are famous games.

The point here is that you might and should use scripting if it simplifies application development but the time when they would be used to code the time critical logic is yet to come...

Thats pretty cool. I thaught it was used in more games, but i wasnt sure.

but i still wouldnt use a managed or scripted language for the core engine stuff (e.g drawing)

My brother and I are actually in the midst of writing a "game engine", and I can tell you it is no small task. If you're looking to get a game put together in less than a couple of years (at least concerning an MMORPG), writing from scratch is probably not a good idea. That being said, it's definately a rewarding experience if you've got the patience.

From what I've seen so far, the basic ingredients are as follows:

Data(base) Engine - Load/Save information about the game
Rules Engine - Make it fair (and have a plot line)
Physics Engine - Make it look real / behave properly
I/O Engine - Make it interactive (handle keyboard/mouse)
Audio Engine - Make it sound good
Display Engine - Put it on the screen

And if you're doing a network game

Network Engine - Make it talk to the world

Again, that's what I've seen so far. It does depend on the type of game you're making, too. For example, if you're making a puzzle game, physics (at least real-world physics) aren't going to matter too much to you.

Anyway, I wish you the best of luck in your endeavor! This can be a whole lot of fun, if you're one who likes a challenge!

PirateTux

I don't think java is slow many games are made in java which are leading this time atleast its better then c or c++....

I don't think java is slow many games are made in java which are leading this time atleast its better then c or c++....

I disagree

I disagree as well... From an language architecture standpoint, C and C++ are always going to be better than Java, simply because of Java's dependance on the Virtual Machine. While Java is always getting better, that layer will always cause Java to execute (for the most part) slower than any compiled C / C++ application.

For high-performance audio and video, C / C++ is the way to go.

Isnt the JVM itself written in C?

The Java specification doesn't mandate the JVM to be written in any particular language, but yes, it's almost always written in C like other VM's out there.

But you have got to realize that Java is an interpreted and not a compiled langauge. The java code is compiled by the 'javac' tool into a class file which is then loaded by the 'java' interpreter which interprets the bytecode and executes the given program. There is on the fly conversion from the java byte code(which is machine code to the java machine) to machine specific code.

At present, there is very slick chance of interpreted languages beating the performance offered by languages which are directly compiled to platform specific machine code like C and C++.

A rule of thumb: You don't gain abstractions for free.

Java is an interpreted and not a compiled langauge. The java code is compiled by the 'javac' tool into a class file

Is .NETs CLI/CLR the same idea?

> Is .NETs CLI/CLR the same idea?
Since I am not involved with C# in any way, I would be in no position to answer that question but it seems that C# code is compiled to an intermediate byte code called IL which is converted on the fly into machine code.

Asking the same question in the C# forums would be more yieldy.

Is .NETs CLI/CLR the same idea?

Yes, I'm pretty sure that that's the case. I know for a fact that .NET requires a VM and I do a little bit of Mono and a runtime VM is required to run any mono application.

The JVM can actually mean that your Java bytecode will run more highly optimised than any native compiled C or C++ code can.
The JIT compiler can provide runtime code optimisation which in a native compiled language is impossible.
As a result it can provide far more tuning of the machine instructions to the exact specs of the computer it is running on than is possible with a native compiled language.

The main area where code running inside a VM is slower (if the VM is good, and the JVMs provided by Sun and some others are very good) is in the loading time of the executable code, as that has to include final compilation into machine code which native compiled code doesn't need.
When finally executing, it will often run as fast as or faster than that native code.

This is shown time and again when doing realistic comparison between Java and native code.
If the application is shortlived, native code is faster (in extreme cases completing before the JVM has completed loading). For longlived applications though the Java code will execute at least as fast as comparable C++ code (if both are written to the same quality standards, rather than as is often the case with "tests" setting out to show that "Java is slow" the C++ code being highly optimised and the Java code deliberately poorly constructed).

And oh, Java is NOT an interpreted language.
It used to be, in the 1.0 release, a language that used interpreted bytecode.
Since the introduction of just in time compilers around 1997 it has been native compiled.
It's just that that native code is constructed on the fly during class loading rather than in advance during initial compilation.
Effectively the JVM is presented with what in C/C++ lingo would be object code, the code that's output by the compiler and presented to the linker.

Java itself is not slow, as others have already said it. But garbage collection (memory reorganization), which the JVM does from time to time can halt the execution of the program for some time. This manifests itself as a short lock in a real-time application like a 3D game. The Java program can be optimized, so that it produces no garbage, so no garbage collection will happen. Sadly this optimization is tedious work, just like optimizing C code. The best approach is using both Java and C, and linking the compiled C library dynamically to Java. If you are interested in a simple to learn Java game engine, check out jMonkeyEngine.

I can't see any gain in using Java over C++ in games unless it was always much faster in execution speed than C++, or provided some functionality or freedom that C++ doesn't; which it isn't, and doesn't. Like C++, Java can only ever hope to equal the speed of optimized machine code, and if it met the speed of machine code generated from C++ :- so what, it doesn't have the same existing 3rd party useful-for-games libs as C++ does at the moment, the standard library isn't as good ( I like simple and general rather than complex and all-encompasing ) all acccess to the OS/videocard is via a higher abstraction layer as exists in C++, garbage collection is a problem I suppose ( but the same strategy VeAr just outlined - minimizing collection, should be employed for C++ games anyway, i.e. minimizing allocations/deallocations on the heap during time-critical periods of runtime- even pre-arranging heap objects using estimated usage frequency/order, but you couldn't hope to do that in the Java as I know it ), the language architecture just isn't optimum anyway beyond prototyping - if I know the lifetime of an object, and that it should be stack allocated, I want to specify that explicitly in the code, not perhaps imply it in the design.

There's nothing special in Java that doesn't exist in C++, thread stuff is arguably made simpler across different platforms, and the general multiplatform aspect is a good thing - but this doesn't matter if you're releasing for a number of specific platforms. C++ can easily be written in a write once/compile anywhere way, and optimized for either platform at compilation - which is as good as compile once run anywhere in any case I can think of. The only other possible benefit for using one language over another is flexibility, and there's not much between the two, especially in terms of what most games require. A better model IMO is to use C++ and/or C for the raw engine and embed to or call from a very dynamic interpretted language, one that is significantly different to C++, either in terms of capabilities, application scope, or simplicity. Think Lisp, Prolog, Python, Lua or ECMAScript << none of these are 'C++ like', and all have different usefulness/simplicity/structure/writing-style scope. What's the scope of Java that falls outside that of C++???

There are certainly good places to use Java - server applications, mobile phone/web-based games, etc. But not for the client end of a 3D FPS engine on PC/console with hot physics, graphics and the rest. Why even try? You'd have little to rely on in terms of existing libraries, you wouldn't be able to hand optimize the code as far as you can in C++, you'd have to adopt OO religiously and be unable to use an 'objects are laid-out memory' approach anywhere, you'd have to wrestle with a garbage collector and have no idea where allocated objects 'go' rather than being able to just allocate in one place and remember to clean up; and for those setbacks, all you'd potentially gain is speed in that you'd only be writing network/thread code once rather than n times ( where n is the number of target platforms ), and a reflection system which honestly isn't very appropriate during realtime, nor particularly special.

C++ provides all a game developer really needs for the rawest part of the engine; perhaps a scripting framework ( inside or outside ) could augment that, but Java as the scripting language? Might aswell write the whole game in C++.

The main issue here is not which language will execute faster .... it hardly matters for most computers when the games are mid to small, there will be plenty of processing power left over.

Only huge 3D games will require the raw power C/C++ allows, but as there's more complexity and time overheads associated with C/C++ coding.

Java may have it's restrictions but when it comes to cross-platform compatibility, it wins hands down against C++..... and for many developers that is more important factor.

Lower level acess for C/C++ makes it more difficult to make it totally cross-platform, and you will need separate binaries for each.

If you want to do cutting edge stuff C++ is the way to go. All the latest APIs, Engines etc use it and it saves a lot of time in development.

If you want cross-platform compatibility and easy of deployment or do small time stuff.. java ... although it has improved a lot and now you have DX and OGL bindings in java... so you can do cutting edge stuff there, but it would be a bit slower.

So to finish this off C/C++ or Java it does not really matter for most games. If you do comparisons efficiency would almost be at par. It's mostly deciding which lang would be more efficient for you to code in and deploy.

Large 3D games are out of reach for java atm, but there are promising engines out there, using java technology to bring 3d games into the browser and with better hardware we get these days .... who knows.

Agreed.. But I don't see C++ as more, or Java as less time consuming to work in than any other language, once I know what needs to be done and how to best go about it. Depending on the app, C++ might be easier : with third party libraries, the need to write code for different platforms in C++ can often be removed anyway - graphic libs, input libs, thread libs, network libs; they are written to be machine independant with a common interface. I guess that's the whole point of Java, in that it's ALL a common interface; which is, I suppose, a natural progression. If more game-specific libs were available on Java, and if the language wasn't so abstracted and neutered; It'd perhaps be a better choice for 'bigger' games than it is at the moment. Unrelated; I actually prefer C# to Java, although it's still lacking in terms of the capabilities afforded by the base language - no multiple inheritance, no 'const' in the C++ sense, no stack-allocated class-type ( polymorphically-capable ) objects, forced non-deterministic garbage collection and no manual memory management... But, you can write inline code with pointer arithmetic, and marshal C++ objects in and out of the managed system, pass-by-value or reference in some circumstances, use closures/anonymous functions, use a function pointer-like/event-based syntax, it's quite fast to work in, since it has a reasonable DX-wrapping game framework library that works on the XBox 360 and PC. But, poor support outside of Microsoft platforms of course...

> There's nothing special in Java that doesn't exist in C++
Security as a language feature.

> A better model IMO is to use C++ and/or C for the raw engine and embed to or call
> from a very dynamic interpretted language
This approach has been used from times unknown. Letting C/C++ handle the rendering / physics while the developer can script away the entire game is the way to go. Graphics Engine / Physics engine / Particle engine come in as pluggable modules with a well exposed API. Look into games like 'Severance the Blade of Darkness or Freedom Force' which use Python as the scripting language.

> But not for the client end of a 3D FPS engine on PC/console with hot physics, graphics
> and the rest.
Agreed. Java has a long way to go.

>Why even try?
Because success comes to us only when we get used to failures.

> So to finish this off C/C++ or Java it does not really matter for most games.
It does matter. Every layer of abstraction has it's own price to pay. When we run C++ programs, what we run is raw machine code. When we run java programs, what we run is the JVM which loads the bytecode, converts it into machine code using JIT which is then executed.

>Unrelated; I actually prefer C# to Java,
Microsoft made a smart move by coming up with XNA in an attempt to push C# as a mainstream game programming language. Maybe java needs to do something along those lines...

I think java needs a batter IDE. Netbeans is crap compared to VisualStudio

Java has excellent IDEs. IntelliJ is second to none, far superior to MSVS (and a lot cheaper too).
Eclipse and JBuilder aren't bad either.
Netbeans indeed is a disaster.

>> There's nothing special in Java that doesn't exist in C++
>Security as a language feature.
Networking as a language feature.
Multithreading as a language feature.
Standardised user interface libraries as a language feature (less useful for games as those generally don't use regular user interface elements).

Java was never conceived for making games, but it's quite capable if used by people who know what they're doing.
The main reason there's not been major adoption in the game industry is the incredible resistance to change in that industry, an industry where many still work in raw assembler or C because they consider C++ "too slow" (or too cumbersome, too modern, and a variety of other non-reasons).
Java is over a decade younger than C++, and is only now gaining acceptance.

There are several game engines (including complete 3D engines) for Java out there, and far more serverside code for game servers that use C++ (for example) client applications on a Java backend.

http://www.jmonkeyengine.com/ is a good example. I've not used it but it certainly looks powerful.

Project Darkstar (Project Darkstar Community - Home), developed by Sun Labs, is also taking aim at massive online games on Java.

Standardised user interface libraries

You mean swing?

Swing indeed. And before that AWT (which is still at the back of Swing in the non-visual area).
There's nothing like that for C++. Each compiler and platform has its own user interface libraries, and often a plethora of them, some of which work only on some platforms and libraries and others on others.

I think java needs a batter IDE. Netbeans is crap compared to VisualStudio

Yeah I agree with Bennet. I think microsoft have been clever by releasing the express editions without any time restriction clauses. It has restrictions with databases but the express editions are more or less the polished end product. I noticed intelliJ has a 30 day trial period, so if it is as good as Wenting says, which I'm sure it is, the restriction would put a lot of people of.

In that case it is no wonder why a lot of people go on about the ease and superiority of visual studio. I think sun needs to do something about that perhaps?

Yeah I agree with Bennet. I think microsoft have been clever by releasing the express editions without any time restriction clauses. It has restrictions with databases but the express editions are more or less the polished end product. I noticed intelliJ has a 30 day trial period, so if it is as good as Wenting says, which I'm sure it is, the restriction would put a lot of people of.

In that case it is no wonder why a lot of people go on about the ease and superiority of visual studio. I think sun needs to do something about that perhaps?

Yeah, IMHO the express editions are almost exactly the full ones except for the lack of some things relating to databases, deployment, source control and mobile development